Re: Metadata Storage Daemon

> 1) A simple metadata storage service over dbus would be quite simple,
> obviously better API's cost us more time and energy, but the backbone
> of such a system is extremely rudimentary. I propose that we just go
> ahead and write one. No desktop search or filters etc. Just a few
> calls exposed to dbus to store, query and delete Triples (A Combo of
> some uniqueid, data, and the datatype/metadata). At its core this is a
> sqlite db with a little extra work.
so, what you are proposing is a central desktop metadata store which is
used by beagle (and other applications) to store its data into? Would
this replace beagle's lucene indices? Or is it a parallel store to
publish beagle's metadata?

> Anyways,  Please share API thoughts so we
> can at least pick a general direction. I would be really interested to
> know a little more about the more elaborate potential use cases.
> Honestly, I see 80% of use being:
> 1) Add lots of attributes for a Uri
> 2) Query for all attributes associated with a Uri or Query for a
> specific attribute associated with a Uri
> 3) Query for Uri sets that have a certain value in a certain
> attribute. * (This starts to venture into the realm of our indexers
> obviously this is a regular use case, and we would need it plenty, I'm
> just noting that any spec we try to make from this should probably
> _count_ on the other desktop searches indexing their metadata, so we
> really just filter on them.)
Also Query for Uri sets that have a keyword in a certain or any
attribute. This would then be some kind of keyword search over the
metadata store to get URIs that match the keyword query. With 2) you
then get all data about the URI.

What would also be simple to include but will increase ubiquity are
attributes of URIs that point to other URIs. So the values of metadata
are not restricted to strings or numbers, but can also be URIs again.

Enrico M.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]