[Nepomuk] Re: Special Identifying Properties

[Sebastian Trüg]

On 07/27/2011 11:42 PM, Vishesh Handa wrote:
> 
> 
> On Thu, Jul 28, 2011 at 12:46 AM, Sebastian Trüg <trueg at kde.org
> <mailto:trueg at kde.org>> wrote:
> 
>     How about another parameter instead which specifies these kind of
>     properties in a list. Then a client can define what makes sense.
> 
> 
> That would increase the complexity of storeResources from a clients
> point of view. But I suppose we should provide overloaded variants of
> storeResources.
> 
> The reason I want to specify this in the ontology is that I can't think
> of a single use case where any of these properties would not be globally
> identifying. Here is an idea : Maybe we could mark these properties as
> InverseFunctionProperties ( inverse cardinality = 1 ), that way we know
> for a fact that they are globally identifying.

This does sound very reasonable.
BUT: the email is NOT such a property. It is a common use case for
families to share an email address. Still, they are different people.

Cheers,
Sebastian

>  
> 
> 
>     Just an idea...
> 
>     Cheers,
>     Sebastian
> 
>     On 07/27/2011 04:53 PM, Vishesh Handa wrote:
>     >
>     >
>     > On Wed, Jul 27, 2011 at 8:13 PM, Sebastian Trüg <trueg at kde.org
>     <mailto:trueg at kde.org>
>     > <mailto:trueg at kde.org <mailto:trueg at kde.org>>> wrote:
>     >
>     >     could you please elaborate on the need of a primary key type of
>     >     property. Give an example maybe...
>     >
>     >
>     > Of course
>     >
>     > Imagine I already have a contact in my repo -
>     >
>     > <nepomuk:/res/somecontact>
>     >     a nco:PersonContact ;
>     >     nco:fullName "Some name" ;
>     >     nco:hasEmailAddress <someEmailRes> .
>     >
>     > Now I decide to push some data using storeResources
>     >
>     > SimpleResource res;
>     > res.addType( NCO::PersonContact() );
>     > res.addProperty( NCO::hasEmailAddress(), QUrl("someEmailRes") );
>     > res.addProperty( NCO::fullName(), QLatin1String("Some other name") );
>     >
>     > This contact would normally not get identified as
>     > <nepomuk:/res/somecontact> as it has a different first name. However,
>     > two people can never have the same email address, so in this case it
>     > *should* get identified as <nepomuk:/res/somecontact>. ( Merging would
>     > obviously fail, but that is another issue, we could be using
>     > OverwriteProperties )
>     >
>     > If we marked nco:hasEmailAddress as Globally Unique, then the
>     SimpleRes
>     > would get mapped to <nepomuk:/res/somecontact> as the email matches.
>     >
>     > Same is the case for nfo:hashValue
>     >
>     >
>     >
>     >     On 07/27/2011 04:26 PM, Vishesh Handa 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.
>     >     >
>     >     > --
>     >     > Vishesh Handa
>     >
>     >
>     >
>     >
>     > --
>     > Vishesh Handa
> 
> 
> 
> 
> -- 
> Vishesh Handa