[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