Re: [JemBlog-Develop] Input Templates

[Ian D. <ia...@in...>]

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