[Nepomuk] Re: Special Identifying Properties

[Christian Mollekopf]

Hey,

as I understand it, you want to use this to merge resources, right?
While I generally agree that it would be useful to have these  
"globalIntentifyingProperty",
to be able to merge automatically, I don't think that should happen on an  
InformationElement level.

It is very well possible that I have two nco:Contacts for the same person  
in the database, and I don't want to get them mixed (i.e. from a private  
and a business addressbook)
I think currently we have 3 levels of describing a resource:
-DataObject: defines where the contact is actually stored (i.e. akonadi or  
the filesystem)
-InformationElement: The actual contact, but just as is (there shouldn't  
be any merging on this level)
-PIMO: this is the level where we can pull together the information  
gathered from all matching InformationElements

So overall it's a like a pyramid with one pimo item on top, generated from  
multiple InformationElements and each InformationElement can come from  
multiple "physical" locations (DataObjects).

This just to clarify regarding the overwriting of properties, and how this  
globalIntentifyingProperty is used.

Your nxx:globalIdentifyingProperty seems good to me, as long as those  
properties are really in all usecases
absolutely globally unique (which is correct afaik for the examples  
mentioned), otherwise it seems dangerous to base automatic merging on it.

But there might also be cases where it would make sense to use something  
which is not really globally unique (like a name or so),
for merging (i.e. when the application only works on a given set of  
resources, where it knows that the property is unique).
Therefore we should also consider adding this option to storeResources or  
the graph instead.

However there is no decent example coming to my mind atm, maybe you guys  
feel more inspired.

Cheers,
Christian


On Wed, 27 Jul 2011 16:26:02 +0200, Vishesh Handa <handa.vish at gmail.com>  
wrote:

> Hey Everyone
>
> Martin and I were discussing storeResources yesterday, and we stumbled on
> the need to have certain properties act as Primary Keys for Resources.
> Currently, storeResources treats the nie:url as a Primary Key, only if  
> the
> nie:url is not present does it use the literal identification scheme (  
> read
> datamanagement.h for more info )
>
> With Martin working on pimo:Person and nco:PersonContact aggregation, he
> requires the nco:hasEmailAddress to act as a Primary Key. Additionally I
> would like nfo:hashValue to act as one. So now that we have 3  
> contenders, it
> makes sense to mark these properties in the ontologies as globally
> identifying or something.
>
> What do you guys think? If you approve, can you suggest a way to mark  
> these
> properties?
>
> One option is that we have a nxx:globalIdentifyingProperty, and make
> nie:url, nco:hasEmailAddress, and nfo:hashValue subclasses of it.