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 ).<br>
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).<br>
<br><div class="gmail_quote">On Wed, Jul 27, 2011 at 11:16 PM, Sebastian Trüg <span dir="ltr"><<a href="mailto:trueg@kde.org">trueg@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
How about another parameter instead which specifies these kind of<br>
properties in a list. Then a client can define what makes sense.<br>
<br>
Just an idea...<br>
<br>
Cheers,<br>
<font color="#888888">Sebastian<br>
</font><div class="im"><br>
On 07/27/2011 04:53 PM, Vishesh Handa wrote:<br>
><br>
><br>
> On Wed, Jul 27, 2011 at 8:13 PM, Sebastian Trüg <<a href="mailto:trueg@kde.org">trueg@kde.org</a><br>
</div><div><div></div><div class="h5">> <mailto:<a href="mailto:trueg@kde.org">trueg@kde.org</a>>> wrote:<br>
><br>
> could you please elaborate on the need of a primary key type of<br>
> property. Give an example maybe...<br>
><br>
><br>
> Of course<br>
><br>
> Imagine I already have a contact in my repo -<br>
><br>
> <nepomuk:/res/somecontact><br>
> a nco:PersonContact ;<br>
> nco:fullName "Some name" ;<br>
> nco:hasEmailAddress <someEmailRes> .<br>
><br>
> Now I decide to push some data using storeResources<br>
><br>
> SimpleResource res;<br>
> res.addType( NCO::PersonContact() );<br>
> res.addProperty( NCO::hasEmailAddress(), QUrl("someEmailRes") );<br>
> res.addProperty( NCO::fullName(), QLatin1String("Some other name") );<br>
><br>
> This contact would normally not get identified as<br>
> <nepomuk:/res/somecontact> as it has a different first name. However,<br>
> two people can never have the same email address, so in this case it<br>
> *should* get identified as <nepomuk:/res/somecontact>. ( Merging would<br>
> obviously fail, but that is another issue, we could be using<br>
> OverwriteProperties )<br>
><br>
> If we marked nco:hasEmailAddress as Globally Unique, then the SimpleRes<br>
> would get mapped to <nepomuk:/res/somecontact> as the email matches.<br>
><br>
> Same is the case for nfo:hashValue<br>
><br>
><br>
><br>
> On 07/27/2011 04:26 PM, Vishesh Handa wrote:<br>
> > Hey Everyone<br>
> ><br>
> > Martin and I were discussing storeResources yesterday, and we stumbled<br>
> > on the need to have certain properties act as Primary Keys for<br>
> > Resources. Currently, storeResources treats the nie:url as a Primary<br>
> > Key, only if the nie:url is not present does it use the literal<br>
> > identification scheme ( read datamanagement.h for more info )<br>
> ><br>
> > With Martin working on pimo:Person and nco:PersonContact<br>
> aggregation, he<br>
> > requires the nco:hasEmailAddress to act as a Primary Key.<br>
> Additionally I<br>
> > would like nfo:hashValue to act as one. So now that we have 3<br>
> > contenders, it makes sense to mark these properties in the<br>
> ontologies as<br>
> > globally identifying or something.<br>
> ><br>
> > What do you guys think? If you approve, can you suggest a way to mark<br>
> > these properties?<br>
> ><br>
> > One option is that we have a nxx:globalIdentifyingProperty, and make<br>
> > nie:url, nco:hasEmailAddress, and nfo:hashValue subclasses of it.<br>
> ><br>
> > --<br>
> > Vishesh Handa<br>
><br>
><br>
><br>
><br>
> --<br>
> Vishesh Handa<br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Sincerely yours,<br>Artem Serebriyskiy<br>