I am not involved in KDE hacking, so my advice is a bit detached. One thing to add is that we modelled NCO after VCARD which is a RFC. Many address books model their data after vcard. The notion of roles is, I think, not home/office/... . Its more like that a role is "leo sauermann, dfki, researcher" vs "..., gnowsis, ceo". Two different lives for one person. The distinction home/office is a comment on the contactmedium. See vcard rfc.
Hth Am 21.07.2011 um 21:01 schrieb Sebastian Trueg <[email protected]>: > HI Martin, > > On 07/20/2011 02:59 PM, Martin Klapetek wrote: >> On Wed, Jul 20, 2011 at 14:13, Sebastian Trueg <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Martin, >> >> On 07/19/2011 07:46 PM, Martin Klapetek wrote: >>> Hi, >>> >>> I'm working on a GSoC project which implements a proper PIMO:Person >>> creation from PIM data. However I'm facing some issues about which I >>> could use some advices. >>> >>> 1) How to set a photo for PIMO:Person? >>> There may be several NCO:PersonContacts with their own photos, I can >>> pick just one (or let the user choose), but what ontology etc. >> should I >>> use to store the photo in? >> >> I figured we already discussed that. The idea we had was to use >> nao:prefSymbol and nao:Symbol. To that end I even improved the >> documentation of the two[1]. >> There are basically 2 ways to do this (in general, for your case it will >> probably always be the second one): >> 1. Use a freedesktop icon via nao:FreedesktopIcon and nao:iconName >> 2. Use double-typing by adding type nao:Symbol to a nfo:RasterImage >> which is stored on disk (nfo:FileDataObject) or on the web >> (nfo:RemoteDataObject or the upcoming nfo:WebResource[2]). >> >> >> Well yes, we started discussing it but it was right before you had to >> leave, so we never actually got to it :) So if I got it right, I need a >> resource with types nao:Symbol and nfo:RasterImage, which will hold >> property with the image url and then add this resource to Person with >> nao:prefSymbol, right? > > indeed. > >> >> >>> 2) How to pick "the right data"? >>> For example address. Imagine you have three NCO:PersonContacts as a >>> grounding occurence in PIMO:Person and all three have different >>> addresses. We must again choose one as the "main/default" address, but >>> how should I write that into PIMO:Person? Same with emails, phones >> etc. >>> Of course I can simply pick the address from the first >> NCO:PersonContact >>> in the result set, but that may be the wrong one. What do you think? >> >> IMHO use pimo:groundingOccurrence vs. pimo:occurrence. But maybe Leo can >> shed some more light here since he created PIMO. >> >> >> So pimo:occurence for everything and pimo:groundingOccurence for the >> "default" data? But that doesn't really work, because think of three >> properties - email, phone and an address. Each one of these is a >> separate NCO:PersonContact. So they should all be >> pimo:groundingOccurence then, but if for example the NCO:PersonContact >> for address have also email, we're doomed. > > Is it really necessary to choose from different contacts? Can't we just > make one the default and simply "fix" it. For example the address book > one. In combination with the writeback service and its akonadi plugin > which Shan is implementing for his GSoC project this should be rather > simple I suppose. > What would be the downside? > > Oh, and then there are contact roles - maybe we should look into that at > some point, allowing Akonadi to expose details like "this is the work > address" through roles... > >> Btw. when reading the PIMO guide [3], it says on page 31 to copy all >> identifiers. Do I understand it correctly that it should copy all >> identifiers from new NCO:PersonContact into PIMO:Person (and should I do >> that too)? This seems like an unnecessary data duplication. > > I agree that this is not a good idea. Also it is a bit dodgy since you > would have to add the type nco:PersonContact to the pimo:Person since > Nepomuk is very strict that way now. :) > > Cheers, > Sebastian > >> Marty K. >> [3] >> - >> http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/v1.1/pimo_v1.1.pdf >> >> >> [1] https://sourceforge.net/apps/trac/oscaf/ticket/107 >> [2] https://sourceforge.net/apps/trac/oscaf/ticket/105 >> _______________________________________________ >> Nepomuk mailing list >> [email protected] <mailto:[email protected]> >> https://mail.kde.org/mailman/listinfo/nepomuk >> >> _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
