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

[George Goldberg]

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.

--
George