Re: Proposing Tracker for inclusion into GNOME 2.18
- From: Jamie McCracken <jamiemcc blueyonder co uk>
- To: James Henstridge <james jamesh id au>
- Cc: Ross Burton <ross burtonini com>, desktop-devel-list gnome org
- Subject: Re: Proposing Tracker for inclusion into GNOME 2.18
- Date: Wed, 25 Oct 2006 11:12:40 +0100
James Henstridge wrote:
On 25/10/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
You would need to completely flatten the metadata as
Contact.HomeJabberID, Contact.WorkJabberID etc so that all metadata is
If you do flatten things like this, I would hope you'd still be able
to query for people by jabber ID (not caring what role the jabber ID
is for). Would that be the case?
yes. currently you would OR the two fields together but if I include the
metadata relationship stuff then Contact.JabberId can be the parent of
both Contact.HomeJabberID, Contact.WorkJabberID and so be searched
We are a fine grained metadata database but I accept making it easy to
do more coarse grain searches is essesntial
It would be nice as tracker is a freedesktop thingie to avoid evolution
specific naming and also to make it clean and easy for other software to
use. Contacts also have relevance to Emails and instant messaging so
that kind of software might wanna use these contact objects too.
While having standard names for metadata relationship types that
everyone can use is great, there are going to be cases where apps want
to experiment with relationships that haven't yet been standardised.
Would an app be able to do this without modifying tracker? Is there
any guidelines about how a project should namespace such metadata to
make sure it doesn't conflict with what other applications are doing?
the guidlines state that it should be namespaced with the application
name EG "Nautilus.WindowSize" would be an app specific metadata whilst
something like "User.Foo" would be a user defined one
The RDF solution to the namespace problem is to use URIs for the
property names, which have well understood namespacing to start with.
Would you suggest apps using tracker do likewise?
possibly although its a bit cumbersome - we could use the dbus way of
Org.Gnome.Nautilus.WindowSize but im not sure if we need to? Would
application names overlap?
A contact can only have one metadata value per type (this is a primary
For a lot of types of metadata you often have multiple values
associated a single metadata type. For example, I have multiple email
addresses. Having separate "work email" and "home email" metadata
types might solve the problem in a lot of cases, but what if someone
has multiple work emails?
if we use the vCard spec for our contacts then it would depend on
whether vCard supports that?
With everything mapped 1:1 you can then use RDF query to search them
Why would you need a 1:1 mapping to do a query? A query for "contacts
with an email of jamiecc blueyonder co uk" should be possible
independent of the number of email addresses a contact can have.
we need the 1:1 mapping to get/set the values. Whatever we implement we
must have a unique metadata name for a particular service in order to do
that otherwise getting or setting a value would be impossible.
One problem with metadata relationships is that some metadata like in
the above case would only be searchable like Contact.JabberID as the
actual storage would be in Contact.WorkJabberID or Contact.HomeJabberID
so it might get confusing for developers if they try and get the value
of Contact.JabberID which would be NULL.
Mr Jamie McCracken
] [Thread Prev