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

George Goldberg grundleborg at googlemail.com
Mon Apr 4 14:46:44 CEST 2011


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.

[1] http://telepathy.freedesktop.org/spec/Connection_Interface_Simple_Presence.html#Enum:Connection_Presence_Type

--
George


More information about the Nepomuk mailing list