[Nepomuk] Re: Special Identifying Properties

[Sebastian Trüg]

On 07/28/2011 02:25 PM, Christian Mollekopf wrote:
> On Thu, 28 Jul 2011 14:21:23 +0200, Sebastian Trüg <trueg at kde.org> wrote:
> 
>> On 07/28/2011 12:36 PM, Christian Mollekopf wrote:
>>> 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 =)
>>
>> Well, in the case of Akonadi nothing is merged anyway since you specify
>> the url directly.
>>
>> Contact merging is really only done for the case of "anonymous
>> contacts", ie. those that are created as second-level resources.
> 
> Ok, fair enough.
> Since we still might want to have contacts merging also for those
> contacts, we could do that on a PIMO level I assume.
> I.e. as in the android phones, where you get your goolecontacts merged
> with the facebook contacts.

Yes, definitely. I hope Martin's solution does not only include Akonadi
contacts. ;)

>>
>>> 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.
>>>>>
>>>
>>>
> 
>