[Nepomuk] Re: Special Identifying Properties

[Artem Serebriyskiy]

I would agree with Sebastian. Passing list of identification properties as
parameter will increase flexibility. To take best from the both worlds we
can provide a default argument for this parameter,  that will be expanded to
the pre-defined list of identifying properties ( stored e.g. in some other
ontology or somewhere else ).
 This also have an advantage that when we face issuses like "Which of
identifying properties is more identifying then the others ?" we can easily
add more parameters to solve it to function signatures instead of constantly
hacking  ontology( which is, by the way, a standard and must not be changed
very often).

On Wed, Jul 27, 2011 at 11:16 PM, 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.
>
> 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
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>



-- 
Sincerely yours,
Artem Serebriyskiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20110728/770c7f56/attachment.htm