On 25/10/06, Jamie McCracken <[EMAIL PROTECTED]> wrote: > You would need to completely flatten the metadata as > Contact.HomeJabberID, Contact.WorkJabberID etc so that all metadata is > mapped 1:1
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? > 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 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? > A contact can only have one metadata value per type (this is a primary > key constraint) 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? > 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 [EMAIL PROTECTED]" should be possible independent of the number of email addresses a contact can have. James. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
