ok, I see.
On 07/21/2011 09:41 PM, Leo Sauermann wrote: > 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
