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

[Sebastian Trueg]

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