[Xesam] Metadata Storage Daemon

Sebastian Trüg strueg at mandriva.com
Wed Jan 16 05:02:31 PST 2008


On Wednesday 16 January 2008 10:21:18 Kevin Kubasik wrote:
> OK, well the obvious agreement is a need for time/change tracking, I
> added a dbus signal called on inserts and a method to get all new
> triples since a specified timestamp. As for file monitoring, while a
> Gnome-wide service would be nice, I think that it is outside the scope
> of a metadata daemon (personally, open to more discussion on this).
>
> I think that a rudimentary triple store (roughly like what I have
> produced here) is a great _base_ for what we are all more or less
> talking about. I think that the pushes for more searching/indexing
> capabilities of the data here are missing the point, this is more a
> simple storage engine. Powerful desktop search engines like Beagle and
> Tracker can now both index the same stored metadata.

IMHO the indexing should be part of the store. And the search engines should 
then use the store to query the data. Thus, we would have these components:

* Indexer (or better: analyser)
  analyses files and writes the data into the store

* Store
  Simple data store for triples (or quadruples) with a proper RDF API (like   
  Soprano fx ;) for advanced queries and a simpler API to perform stuff like:
  - getAllProperties( uri resource )
  - setProperty( uri resource, uri property, value )
  and so forth which handle time stamping and meta-meta-data updating
  automatically.
  This store also indexes the data and provides a query API which can be used 
  by search engines. This query API is low level and not intended for the 
  end user (I would opt for SPARQL here but I think you know that ;)

* Search client
  Creates queries to the store from user queries.
  (This is what has been described already in XesamQueryLanguage)
  "Final" search clients would then be using this service for queries.
  Thus, searching means three steps: 
     user GUI -> search client service -> Store

* File watch service
  Watches file systems for changes and updates the metadata accordingly.

I think it is important to keep the data in one place here. There is no reason 
to keep separate stores and indexes for data from file analysers and from 
user input (like tags) or any other application that likes to store 
something.

> Anyways, I also added some more robust search/select style methods.
> Please, its so easy to manipulate this API, I ask that if you have
> feelings about something to do with this, and feel like people are
> either
> a) missing the point
> or
> b) misunderstanding you
>
> just branch the code and provide us with a sample of what you are
> trying to accomplish.
>
> https://code.launchpad.net/gnome-metadata-store/+branches
>
> Shows a list of current branches.
>
> Cheers,
> Kevin Kubasik
>
> On Jan 15, 2008 8:26 PM, Evgeny Egorochkin <phreedom.stdin at gmail.com> wrote:
> > В сообщении от Wednesday 16 January 2008 00:59:58 Jamie McCracken 
написал(а):
> > > > > with a dumb metadata daemon you lose it (all the metadata still
> > > > > points to the old file) unless something keeps it in check (which
> > > > > as i said means changing vfs, email apps etc to do this)
> > > >
> > > > That is handled by another service. I don't think it is up to the
> > > > indexer or the store to watch files (well, maybe the indexer to
> > > > update data, ok, sure). And in the end even in your combined solution
> > > > you have two components internally. So for the sake of decoupling and
> > > > cleaner APIs we should define it as different services from the
> > > > beginning.
> > >
> > > the user defined metadata store will be a separate dbus interface
> > >
> > > whether its a separate process is an implementation detail
> >
> > Doesn't make much sense to me. This
> > separation(indexer-provided/user-provided and don't forget app-provided)
> > metadata is better handled on the ontology level to provide flexibility.
> > Of course storage can handle user metadata in a different way like make
> > sure not to corrupt or lose it because unlike file index it can't be
> > rebuilt.
> >
> > -- Evgeny
> >
> > _______________________________________________
> > Xesam mailing list
> > Xesam at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xesam




More information about the Xesam mailing list