RE: [JemBlog-Develop] Input Templates

[Cayzer, S. <Ste...@hp...>]

[PS Apologies if this appears to hijack the list. I'll make up for it by
posting a jemblog message next ;-) ] 

Thanks for these comments Ian, I have been trying out various solutions and
I am far from clear on the best way to proceed, but thought I'd answer those
points I can.

1). UI Configurations.
We went quite far down this path in ePerson[1]. In particular, for example,
a user can specify (in RDF) how they want their component dealt with. We
used Java class names and reflection, but in principle other mechanisms,
such as scripting, would be allowed. We also allowed the user to specify
input filters and validation properties for these classes. Note that the
customisations were global, not per user.
With regard to semblogging, I have a more modest aim. Which is just to allow
the user to select a subset of the schema properties to show in a dialog
box, and also to supply a controlled vocabulary (i.e. list of allowed terms)
for a certain field. I am not proposing the use of RDF/DAML/OWL validation
to infer which properties an instance must/should have, though I may use
datatype information.

2). Servlets vs perl.
Your points are well taken, I have investigated both options and both
methods have strengths and weaknesses. I don't want to get too specific here
since I haven't worked through all the details yet.

3). Design documents
I've got some ready to go, but I want to discuss them with the folks here
first, to clear out the obvious crud ;-)

Cheers

Steve

[1] A lengthy report can be found at
http://www.hpl.hp.com/techreports/2002/HPL-2002-328.html. 
It should however be reasonably modular so you can skip to the items of
interest.  

-----Original Message-----
From: Ian Davis [mailto:ia...@in...]
Sent: 19 March 2003 14:17
To: jem...@li...
Subject: Re: [JemBlog-Develop] Input Templates


On Wednesday, 19 March 2003 at 08:55, Cayzer, Steve wrote:
> What a coincidence!
> I am thinking along exactly the same lines at the moment in HPs semantic
> blogging project [1].
Interesting project - I wasn't aware of it before.

> My idea at the moment is to store a (per user) configuration file (in RDF
of
> course) which specifies these preferences.
> It will look something like what you suggest, except that I would be
> slightly less fine grain about the display options.
> For example, I might specify 'maximum expected size'  for a literal, and
> also a filename which contains a controlled vocabulary to fields such as
> topic. But try to leave fine grain UI configurations to the dialog
builder.
There are several parts to this problem :
a) What properties are applicable to a class
b) What properties are interesting to the user
c) Data typing and validation for properties

b) can be built from a) given a user interface that allows the user to
pick the properties they want. A dialog builder can use b) in
conjunction with c) to build a data capture form.

BTW, I don't know of any existing solutions to these problems.

At first sight RDF schema appears to handle a) but closer inspection
reveals that RDF Schema doesn't dictate what properties a class may
have, but what class an instance is given a property of that
instance. To do a) you have to delve into OWL.

Again, c) appears to be covered by the RDF model which allows
datatyping, but there is no global datatyping so there's no way of
saying that every dc:date has to contain a date. To do c) properly
we have to come up with a vocabulary for describing the data
characteristics of properties in our applications.

I've been thinking about something else in this area too for another
project (www.semanticplanet.com): a way to specify a query on a triple
store. Basically it's exactly the same problem except that the fields
that are filled in are used to generate a query rather than a new
instance of a class.




> Which brings me to Haystack. HP have quite close relationships with
> Haystack, I have not seen it in action but have read the papers carefully.
> They do *very* fine grain UI control, which is conceptually attractive but
> computationally expensive (1M triples to specify a startup screen). In our
> 'eperson' work[2] we tried to steer a middle road, and I'd like to try the
> same tack here.
That's a lot of triples, but now I think about it maybe it's not
unreasonable. I wonder how many 'atoms' of information my mail client
is processing just to render this window and let me type?

> One thing I'm not sure about is whether to implement the dialog builder in
> perl or as a servlet. I'm tending towards the latter, partly because it
> integrates better with Jena, partly because it appears that doing it in
perl
> will require hacking the core MT scripts (which I'm loath to do, I want
this
> to be easily deployable) and partly because I'm still a beginner in perl
> (mind you I'm not that hot on servlets either ;-)). Opinions welcome.
If you want to integrate with MT then you could write some Perl
modules that use MT as a back-end API, i.e. call the right method to
save a new posting; call another to build the site. If you want to do
it in Java I'd recommend writing it in a class and then writing a
servlet to call that class. It makes it much easier to write tests for
the class when it's not tied into the UI. Also I'm keen to have a
desktop app that will publish to a website since I (like the majority
of webloggers) don't have a good servlet setup available. (I have one
here at home, but I'm on cable with 128kbps upstream)

> If anyone's interested, I'm writing some design documents and can
circulate
> them to the list.
Yes please.

Ian



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
JemBlog-Develop mailing list
Jem...@li...
https://lists.sourceforge.net/lists/listinfo/jemblog-develop