[Nepomuk] Re: Special Identifying Properties

[Christian Mollekopf]

On Thu, 28 Jul 2011 11:33:20 +0200, Sebastian Trüg <trueg at kde.org> wrote:

> On 07/28/2011 12:28 AM, Christian Mollekopf wrote:
>> Hey,
>>
>> as I understand it, you want to use this to merge resources, right?
>> While I generally agree that it would be useful to have these
>> "globalIntentifyingProperty",
>> to be able to merge automatically, I don't think that should happen on
>> an InformationElement level.
>>
>> It is very well possible that I have two nco:Contacts for the same
>> person in the database, and I don't want to get them mixed (i.e. from a
>> private and a business addressbook)
>> I think currently we have 3 levels of describing a resource:
>> -DataObject: defines where the contact is actually stored (i.e. akonadi
>> or the filesystem)
>> -InformationElement: The actual contact, but just as is (there shouldn't
>> be any merging on this level)
>
> Actually there should and it was the originally reason for us to create
> it. Imagine the email and the mp3 files case. You do not want to have a
> Contact for each and every from header of each and every mail. And you
> do not want a separate Contact as performer for each mp3 file.
>

I agree for emails and mp3 files, because there the different origins,  
really contain exactly the same file.
As I said, InformationElements can come from multiple DataObjects.
But I don't think that this is a smart move for contacts, which are  
similar, but not necessarily identical.

Imagine you have the same person in an addressbook which is shared in the  
company, and a private one.
Both are synced over akonadi for instance, you'll want be able to edit  
both contacts separately, because one will be publicly visible.
If you already merge the contacts on an IE level, there is no possibilty  
to do that reasonably.

This is of course mainly a problem, because IMO nepomuk should eventually  
become a full wrapper for things like akonadi (have writeback  
capabilities),
so i.e. an addressbook doesn't even have to know about akonadi.
The DataObject side is not suitable to edit content of a contact, because  
it only models the container (i.e. the akonadi item), which leaves us with  
InfomrationElement.

So what I'm saying is, while multiple DataObjects can be represented by a  
single IE, there shouldn't be any "smart" merging, as in the case of  
contacts.
The "smart" merging should be left to the PIMO level.

If you really do "smart" merging on an IE level, that will block Nepomuk  
 from becoming a full wrapper and severely limit the options for the future.

IMHO anyways =)

Cheers,
Christian

> Cheers,
> Sebastian
>
>> -PIMO: this is the level where we can pull together the information
>> gathered from all matching InformationElements
>>
>> So overall it's a like a pyramid with one pimo item on top, generated
>> from multiple InformationElements and each InformationElement can come
>> from multiple "physical" locations (DataObjects).
>>
>> This just to clarify regarding the overwriting of properties, and how
>> this globalIntentifyingProperty is used.
>>
>> Your nxx:globalIdentifyingProperty seems good to me, as long as those
>> properties are really in all usecases
>> absolutely globally unique (which is correct afaik for the examples
>> mentioned), otherwise it seems dangerous to base automatic merging on  
>> it.
>>
>> But there might also be cases where it would make sense to use something
>> which is not really globally unique (like a name or so),
>> for merging (i.e. when the application only works on a given set of
>> resources, where it knows that the property is unique).
>> Therefore we should also consider adding this option to storeResources
>> or the graph instead.
>>
>> However there is no decent example coming to my mind atm, maybe you guys
>> feel more inspired.
>>
>> Cheers,
>> Christian
>>
>>
>> On Wed, 27 Jul 2011 16:26:02 +0200, Vishesh Handa <handa.vish at gmail.com>
>> 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.
>>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/