[Xesam] Metadata Storage Daemon

[Mikkel Kamstrup Erlandsen]

On 15/01/2008, Jamie McCracken <jamie.mccrack at googlemail.com> wrote:
>
> On Tue, 2008-01-15 at 15:51 +0100, Sebastian Trüg wrote:
> > On Saturday 12 January 2008 00:05:38 Mikkel Kamstrup Erlandsen wrote:
> > > 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?
> >
> > That has nothing to do with the D-Bus interface. I thought we were looking for
> > an API?
> >
> > > 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.
> > >
> > > > Timestamps are handled via named graphs [2], also known as context (RDF
> > > > quadruples).
> > >
> > > Are you suggesting putting the mtime in the name of each RDF triple?
> > > If we are to support timestamps I don't think we should expose them as
> > > RDF quadruples because I still think that it is too much abstraction
> > > to present to the end user developer.
> >
> > No, named graphs mean that each triple becomes a quadruple and the forth node
> > is used to group triples together into subgraphs. These subgraphs are then
> > annotated with arbitrary information such as creation date.
> >
>
>
> it (quad-store) sounds quite bloated
>
> would it not be better to have a single metadata_changed_timestamp
> attribute on the entity itself rather than on each and every triple/quad
> metadata item?

Well that depends on what we want :-)

Having each triple annotated gives a very fine grained timeline that
one might be able to use to something cool. As you point out, it does
give an overhead since each entity might have many properties.

I think the question about these timestamps is really - what are we
planning to use them for? Incremental updates to an indexer has come
up, but are there others?

Cheers,
Mikkel