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

[Sebastian Trüg]

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.

Cheers,
Sebastian