[Xesam] Metadata Storage Daemon

[Evgeny Egorochkin]

В сообщении от 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).

> 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.

> However I thought names had to be unique. Timestamps are generally
> not... Maybe I did not read that Named Graph spec properly.

There are no limitations for graph names. in fact, graph name is just a 4th 
element of the RDF triple so to say :) with the same limitations or rather 
lack thereof.

-- Evgeny