[prev in list] [next in list] [prev in thread] [next in thread]
List: nepomuk
Subject: [Nepomuk] Re: Special Identifying Properties
From: Artem Serebriyskiy <v.for.vandal () gmail ! com>
Date: 2011-07-28 4:49:16
Message-ID: CAJU16cMm8jJWnZdn4j=n5ZNHScZT-69c89O-Ng_JRmkUZwaQKQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
One more issue - compaing 'identifying properties'. For GMail
v.for.vandal@gmail.com and vforvandal@gmail.com are the same email
addresses, but this may not be true for some other mailing systems.
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.
2011/7/28 Christian Mollekopf <chrigi_1@fastmail.fm>
> On Wed, 27 Jul 2011 23:42:50 +0200, Vishesh Handa <handa.vish@gmail.com>
> wrote:
>
> > On Thu, Jul 28, 2011 at 12:46 AM, Sebastian Trüg <trueg@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.
> >
>
> The akonadi item uris are something which is not really globally unique,
> but unique on a single system.
> So, they could really be used for identification, but not accross several
> systems, and should therefore not be marked in the ontology directly.
> Still, we could mark the ones that really are globally unique.
>
> >
> >>
> >> 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@kde.org
> >> > <mailto:trueg@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
> >>
> >
> >
> >
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> _______________________________________________
> Nepomuk mailing list
> Nepomuk@kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
--
Sincerely yours,
Artem Serebriyskiy
[Attachment #5 (text/html)]
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>
_______________________________________________
Nepomuk mailing list
Nepomuk@kde.org
https://mail.kde.org/mailman/listinfo/nepomuk
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic