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

Leo Sauermann leo.sauermann at gnowsis.com
Thu Jul 21 21:41:04 CEST 2011


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
>> 
>> 


More information about the Nepomuk mailing list