[Nepomuk] Re: Special Identifying Properties

[Christian Mollekopf]

On Wed, 27 Jul 2011 23:42:50 +0200, Vishesh Handa <handa.vish at gmail.com>  
wrote:

> On Thu, Jul 28, 2011 at 12:46 AM, Sebastian Trüg <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.
>

The akonadi item uris are something which is not really globally unique,  
but unique on a single system.
So, they could really be used for identification, but not accross several  
systems, and should therefore not be marked in the ontology directly.
Still, we could mark the ones that really are globally unique.

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


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/