[Nepomuk] Re: Special Identifying Properties
Vishesh Handa
handa.vish at gmail.com
Wed Jul 27 23:42:50 CEST 2011
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.
>
> 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
>
--
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20110728/02b1a0ab/attachment-0001.htm
More information about the Nepomuk
mailing list