One more issue - compaing 'identifying properties'. For GMail <a href="mailto:v.for.vandal@gmail.com">v.for.vandal@gmail.com</a> and <a href="mailto:vforvandal@gmail.com">vforvandal@gmail.com</a> are the same email addresses, but this may not be true for some other mailing systems. <br>
It is easy when we can pass extra parameters to the storeResource ( e.g. ..., Comparator c, ... ) and may be a little bit harder if we try to predict all this in ontology.<br><br><div class="gmail_quote">2011/7/28 Christian Mollekopf <span dir="ltr"><<a href="mailto:chrigi_1@fastmail.fm">chrigi_1@fastmail.fm</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Wed, 27 Jul 2011 23:42:50 +0200, Vishesh Handa <<a href="mailto:handa.vish@gmail.com">handa.vish@gmail.com</a>><br>
wrote:<br>
<div class="im"><br>
> On Thu, Jul 28, 2011 at 12:46 AM, Sebastian Trüg <<a href="mailto:trueg@kde.org">trueg@kde.org</a>> wrote:<br>
><br>
>> 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>
><br>
> That would increase the complexity of storeResources from a clients<br>
> point of<br>
> view. But I suppose we should provide overloaded variants of<br>
> storeResources.<br>
><br>
> The reason I want to specify this in the ontology is that I can't think<br>
> of a<br>
> single use case where any of these properties would not be globally<br>
> identifying. Here is an idea : Maybe we could mark these properties as<br>
> InverseFunctionProperties ( inverse cardinality = 1 ), that way we know<br>
> for<br>
> a fact that they are globally identifying.<br>
><br>
<br>
</div>The akonadi item uris are something which is not really globally unique,<br>
but unique on a single system.<br>
So, they could really be used for identification, but not accross several<br>
systems, and should therefore not be marked in the ontology directly.<br>
Still, we could mark the ones that really are globally unique.<br>
<div><div></div><div class="h5"><br>
><br>
>><br>
>> Just an idea...<br>
>><br>
>> Cheers,<br>
>> Sebastian<br>
>><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>
>> > <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<br>
>> 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<br>
>> stumbled<br>
>> > > on the need to have certain properties act as Primary Keys for<br>
>> > > Resources. Currently, storeResources treats the nie:url as a<br>
>> 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<br>
>> mark<br>
>> > > these properties?<br>
>> > ><br>
>> > > One option is that we have a nxx:globalIdentifyingProperty, and<br>
>> make<br>
>> > > nie:url, nco:hasEmailAddress, and nfo:hashValue subclasses of<br>
>> it.<br>
>> > ><br>
>> > > --<br>
>> > > Vishesh Handa<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Vishesh Handa<br>
>><br>
><br>
><br>
><br>
<br>
<br>
--<br>
</div></div>Using Opera's revolutionary email client: <a href="http://www.opera.com/mail/" target="_blank">http://www.opera.com/mail/</a><br>
<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>