[Nepomuk] Re: Need some advices about PIMO:Person

[Sebastian Trüg]

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 <trueg at kde.org>:
> 
>> HI Martin,
>>
>> On 07/20/2011 02:59 PM, Martin Klapetek wrote:
>>> On Wed, Jul 20, 2011 at 14:13, Sebastian Trueg <trueg at kde.org
>>> <mailto:trueg at kde.org>> 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
>>>    Nepomuk at kde.org <mailto:Nepomuk at kde.org>
>>>    https://mail.kde.org/mailman/listinfo/nepomuk
>>>
>>>
>