On Fr, 2010-09-17 at 10:49 +0100, Mathias Hasselmann wrote: > We currently have some major changes ongoing: > > - use the contact's tracker:id() for QContactLocalId, > instead of nco:contactLocalUID > - add support for "Other" context, actually arbitrarily contact: > details with "Other" context will be stored within the nco:Contact, > details with "Home" context are moved to an nco:Affiliation with > rdfs:label "Home". > > Therefore I'd prefer answering in detail, once this changes are done.
If I understand it correctly, there will be some issues during upgrade. Existing data will be shown differently after an upgrade, old QContactLocalIds (as using in sync, for example) will become invalid. Perhaps it would be better to include the new schema mapping in MeeGo 1.1. Seems like a fairly intrusive change shortly before code freeze, though. I also had a chat with Mathias about this on IRC (#qtcontacts-tracker on Freenode, for those interested). Here's a summary. On Mi, 2010-09-15 at 15:32 +0100, Patrick Ohly wrote: > > qtcontacts-tracker: > > nco::contactLocalUID, a Maemo/MeeGo extension of > > http://www.semanticdesktop.org/ontologies/nco/, > > custom QContactDetail mapped to nao::propertyName/Value, > > fuzzy phone number search implemented by storing normalized phone number > > in maemo::localPhoneNumber, > > detailed change notifications via > > SopranoLive::BackEnds::Tracker::ClassUpdateSignaler > [...] > Question: are these extensions to the standard NCO documented > > somewhere public? > > Mathias or Aleksandar, do you know? I found that http://library.gnome.org/devel/ontology/unstable/ at least lists them, albeit without much comments. As Mathias said, this is subject to change anyway. > One thing that surprised me is that all "WORK" related properties were > stored in an nco:affiliation. I have not found anything that marks that > affiliation as "work" (as in TYPE=WORK in vCard). Is that implicit? Yes. Will be made explicit soon, see above. > A related question in this context: at which point will that affiliation > or other entities like mailto:[email protected] be removed? In particular the > later might be referenced by multiple different contacts. Perhaps I'm > not using the right vocabulary: what I mean is that RDFs with subject > "mailto:[email protected]"; may or may not become obsolete when the RDF > "contact:xyz nco:hasEmailAddress mailto:[email protected]"; gets removed. > > Experiments show that mailto:[email protected] is not removed. I noticed that there was some discussion around this issue already (not surprising, it's just a matter of finding the information): http://live.gnome.org/Tracker/Documentation/PostProcessing "Cascade on delete will solve the orphan information problem" - not sure what that exactly means, though ;-) -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
