[Xesam] Metadata Storage Daemon

[Sebastian Trüg]

On Sunday 13 January 2008 12:07:25 Evgeny Egorochkin wrote:
> В сообщении от Sunday 13 January 2008 12:12:34 Mikkel Kamstrup Erlandsen
>
> написал(а):
> > On 13/01/2008, Evgeny Egorochkin <phreedom.stdin at gmail.com> wrote:
> > > В сообщении от Saturday 12 January 2008 23:02:18 Mikkel Kamstrup
> > > Erlandsen
> > >
> > > написал(а):
> > > > On 12/01/2008, Evgeny Egorochkin <phreedom.stdin at gmail.com> wrote:
> > > > > В сообщении от Saturday 12 January 2008 01:05:38 Mikkel Kamstrup
> > > > > Erlandsen
> > > > >
> > > > > написал(а):
> > > > > > On 11/01/2008, Sebastian Trüg <strueg at mandriva.com> wrote:
> > > > > > > Just my 2 cents:
> > > > > > > Soprano has a IMOH very good DBus API [1] for RDF storage which
> > > > > > > fulfills all 3 of your requirements below. We already use it
> > > > > > > for Nepomuk and it works great. And since Xesam is already
> > > > > > > using URIs to identify stuff why not go the extra mile to RDF
> > > > > > > storage altogether?
> > > > > >
> > > > > > I thought Soprano depended on Qt?
> > > > >
> > > > > This is not a dependency that you can't easily get rid of.
> > > > >
> > > > > > Anyways, I don't think the RDF quadruples is a good thing to
> > > > > > expose directly to the programmers who just want a quick and
> > > > > > dirty metadata storage. It is simply just too technical. That
> > > > > > does not mean that we cannot use that stuff under the hood
> > > > > > though.
> > > > >
> > > > > Which part of ( URI, property name, property value , timestamp )
> > > > > programmers can't understand and why should it be hidden?
> > > >
> > > > Exactly my point :-)  ( URI, property name, property value ,
> > > > timestamp ) is fine, but exposing the general Named Graph terminology
> > > > (and features)
> > >
> > > Actually there's nothing more to named graphs than another element
> > > added to the triple. So you can differentiate named graphs with
> > > namespacing like mtime:/ uri. Using name graphs only for mtime might
> > > backfire in the sense that named graphs could be used in other ways
> > > like to store provenance info(where speicifc triple came from).
> >
> > That is exactly one problem I have with named graphs. It seems kind of
> > arbitrary to allow exactly one "name" per graph. It kind of begs you
> > to stick on XML blob in it with both mtime, provenenance, and your
> > shoe size in centimeters.
>
> You're right in the sense that quads are arbitrary. Any information
> represented with quads can be as well represented with triples, but a much
> larger number of them. So quads are basically a slight relaxation of the
> absolute minimalism of triples, which often is benefical in practice.
>
> It is also possible to use a xml blob. The question is whether this is
> needed or not.
>
> > > > in the API is too generic to my taste. If we say that the
> > > > triple name is always a timestamp I am ok with it.
> > >
> > > Actually generic API is the only one that's really needed, because it
> > > is the most powerful. This doesn't exclude having a set of convenience
> > > functions to do typical queries or even completely hide the RDFish and
> > > SPARQLish nature of the matter for certain users of the technology.
> >
> > The most powerful and generic API is not always the right one to
> > expose. You have to design the API so that the consuming programs also
> > get a lot of expressive power and clarity. That is rarely a quality of
> > totally generic interfaces.
>
> I didn't say you shouldn't expose simpler/specialized apis. I said it makes
> no sense to intentionally disallow access to the most generic API.
>
> > Consider the following lines of code could be the same:
> >
> > double val = item.getValue();
> > double size = shoe.getShoeSize();
>
> However for a code that deals with T-shirts, item.getValue() is better than
> shoe.getShoeSize().
>
> > If you are writing stuff that should really be generic (ie a generic
> > RDF backend) then 1 is fine. If you are writing an application to
> > manage a shoe store 2 would likely make things a lot clearer. Ofcourse
> > this example is exaggerated, but I think the idea is clear.
>
> If your application is managing a shoe store but uses RDF as a backend,
> it's unreasonable to completely disallow the access to RDF interface.
>
> > Our target is "Metadata Storage for the Desktop". Not "Generic Named
> > Graph Storage" and our API should reflect this.
>
> Metadata Storage for the Desktop is just as ambiguous as a Generic RDF
> Backend.
>
> What metadata are we talking about? Settings? Annotations? How about
> external data sources like IMAP or a FOAF provided by a social networking
> site? Where do we draw the line and should we?

Exactly. IMHO metadata on the desktop has a very wide and open range. Thus we 
need a pretty generic API. We can always add additional convenience stuff 
that handles most every-day uses but having something generic is not a bad 
idea.

And the Soprano API could also provide just a starting point. If we can come 
up with some restrictions, we can include them and define some generic 
behaviors that the API should follow.

> > If absolute generic'ism was the best thing in the world all APIs would
> > consist of var arg functions:
> >
> > Object get (Object obj, ...)
> > Object set (Object obj, ...)
>
> That's exactly what template metaprogramming and similar approaches are
> doing, with some success mind you.
>
> As to specific/niche APIs, ontology is exactly the solution for this. RDF
> backend is generic, but specific ontology consisting of classes and
> properties provides human-friendly solutions for specific problems.
>
> If you use a generic RDF backend doens't mean you really have to operate in
> RDF realm. You still can use constructs like:
>
> int length = aMessage.getLength()
>
> Unless your programming language can't feasibly support such constructs of
> course.
>
> Soprano is a generic RDF backend, still you get to manipulate high-level
> objects defined by an ontology and not RDF triples or anything low level
> like this(unless you really want to).
>
> Yet Soprano is not tied to any specific ontology, API or approach.
> Switching say from FOAF to Xesam is a matter of providing an ontology
> description file, which none of concern for Soprano devs and other users of
> the system.
>
> -- Evgeny
> _______________________________________________
> Xesam mailing list
> Xesam at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xesam