[Nepomuk] Re: Some (a lot of) ideas for/issues with the Nepomuk ontologies

[Sebastian Trüg]

Hi George,

sorry for the late reply. I took an extended parental leave in the wake
of the birth of my second daughter. :)

As for your patch. Very nice, I only have two comments:
1. IMHO the new type should simply be called nco:IMStatusType, the
"identifier" suffix seems random to me. Also we already use distinction
by case in some cases.
2. I would add labels to the predefined types so that simple apps do not
need to bring their own.

Cheers,
Sebastian

On 04/17/2011 06:35 PM, George Goldberg wrote:
> On 4 April 2011 14:06, Sebastian Trüg <trueg at kde.org> wrote:
>> On 04/04/2011 02:58 PM, George Goldberg wrote:
>>> On 4 April 2011 13:55, Sebastian Trüg <trueg at kde.org> wrote:
>>>> On 04/04/2011 02:46 PM, George Goldberg wrote:
>>>>> On 4 April 2011 13:14, Sebastian Trüg <trueg at kde.org> wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> before creating tons of tickets for SDO I would like to discuss some of
>>>>>> the issues I see with the ontologies. So here goes. Please comment.
>>>>>
>>>>> <snip>
>>>>>
>>>>>> * nco:imStatus has a string range. That is just awful. Especially since
>>>>>>  there is also nco:imStatusMessage which can be used to store an
>>>>>>  arbitrary message. nco:imStatus should have a resource range with a
>>>>>>  dedicated nco:ImStatus type and predefined instances.
>>>>>
>>>>> Actually, this is pretty tricky. There are a lot of IM networks out
>>>>> there, and they have a huge range of different presence statuses. In
>>>>> fact, some (jabber) even allow arbitrary strings for this. So, I don't
>>>>> really see how you can ever hope to catalogue the full range in an
>>>>> ontology. Telepathy solves this problem as such: (the simplest way
>>>>> that doesn't require fudging it)
>>>>>
>>>>> Presence consists of 3 parameters:
>>>>>  - status (string)
>>>>>  - status type (enum)
>>>>>  - status message (string)
>>>>>
>>>>> Starting with the easiest of these: status message. This is just the
>>>>> arbitrary text string that users can add to their presence such as
>>>>> "I'm on the phone, I'll be back later".
>>>>>
>>>>> status is also an arbitrary string, as explained above. However,
>>>>> applications are supposed to try and parse this string, and use it to
>>>>> define the presence state if they recognise it. This takes care of 90%
>>>>> of cases, where just typical strings like "available" "away" "xa"
>>>>> "busy" etc are used. In the remaining 10%, where the string is not a
>>>>> commonly supported value, or is not recoginised by the application (as
>>>>> some applications with special use cases may understand some
>>>>> non-common strings here), then the application falls back to the
>>>>> status-type to establish the presence status.
>>>>>
>>>>> status-type is an enum, as documented here [1]. It lists the common
>>>>> types of presence status, such as available, offline, unknown, away,
>>>>> xa, busy, etc. This can be used if the presence string is not
>>>>> recognised.
>>>>>
>>>>> In KDE-Telepathy, we store the status as the nco:imStatus property and
>>>>> the status message as the nco:imStatusMessage property. We also have a
>>>>> custom field in our telepathy ontology which stores the status type.
>>>>>
>>>>> In conclusion, perhaps the thing to do is to keep the imStatus as it
>>>>> is, and then add a imStatusType property to nco, which has a resource
>>>>> range with predefined instances as the type (based on that enum from
>>>>> Telepathy [1]), and then document the way presence should be used in
>>>>> NCO by applicatons as the same method I've explained above that we use
>>>>> in Telepathy? I can write a patch for this if you agree.
>>>>
>>>> I do agree fully. :)
>>>> Thanks a lot for explaining.
>>>>
>>>> But just to be clear: IMHO the imStatusType should *always* be set and
>>>> the imStatus *can* be used to provide finer grained access. This way it
>>>> is very easy to determine the rough state of an IM system without
>>>> parsing a string. IMHO this is useful for many apps.
>>>
>>> I know what you mean, but I think that both should always be set.
>>> Certainly, any IM program putting this data there should be able to do
>>> that. And applications should be encouraged to use the text string as
>>> much as possible, simply because in the cases when they recognise it,
>>> they can get more meaning out of it.
>>
>> very good - so "set one, set both" is the idea. If you could write that
>> patch that would be great. :)
>> Or create a branch in sdo on sf if you can.
> 
> First draft of these changes is ready for review here:
> 
> http://cgit.freedesktop.org/~gberg/ontologies/commit/?h=presence-clarification
> 
> 
> --
> George
>