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

[George Goldberg]

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