<br><br><div class="gmail_quote">On Thu, Jul 28, 2011 at 12:46 AM, 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></blockquote><div><br>That would increase the complexity of storeResources from a clients point of view. But I suppose we should provide overloaded variants of storeResources.<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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></blockquote></div><br><br clear="all"><br>-- <br><font color="#999999">Vishesh Handa</font><br>