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

[Sebastian Trüg]

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.

Cheers,
Sebastian