RE: Update of the Ontology Covering 'Facets' of properties

Hi Jose,

I think that such metaproperties could be needed for some kinds of
property, but not necessarily all. For example, in the case of the pixel
size in my example, the DDR can tell from the actual values of the minimum
and maximum. For different kinds of property, there may be other ways to
infer this.

I was trying to avoid explicit 'flags' at this point, hoping that we might
find a more fundamental way to infer variability from the data itself. I'm
hoping that we might find some standard patterns in the ontology, and that
we might be able to define the inference rules for those patterns.

Best wishes
Rhys

  _____

From: jmcf@tid.es [mailto:jmcf@tid.es]
Sent: 04 May 2007 13:14
To: Rhys Lewis
Cc: public-ddwg@w3.org
Subject: Re: Update of the Ontology Covering 'Facets' of properties


Hi Rhys,

One question that comes to my mind. How a DDR is going to know that a
property can change or not between different instances of a device? I
think that in the ontology  there should be metaproperties, i.e some kind
of properties about properties that indicate if a property can change
between different instances of a device, or if a property can have default
values, etc.

What do you think?

Best regards

Rhys Lewis escribió:

Hello everyone,

Following the various discussions we've had about the nature of
properties, I've uploaded a new, publicly accessible version of the
ontology to explore some of the ideas [1]. I've been looking at possible
representations both for properties that have some aspects that don't vary
and some that do.

I took the values for the total and usable number of pixels in the
horizontal and vertical directions of a display and worked on them based
on our recent debates. In previouls versions of the ontology, (for example
[2]) these properties were represented as single values. As a result of
discussion, we came to the conclusion that that was insufficient. We
recognised that it is possible for some properties to vary on some
devices. We also recognised that for some properties, the DDR could not
store the actual current value of a property, because that could only be
found by asking the device itself. On the other hand, even in these cases,
the DDR could store useful information, such as the range of values that a
property could take or a default value.

Let's look at a couple of concrete examples. I'll use
'hasTotalDisplayPixelsY', the total number of pixels on the display in the
vertical direction as a one example, and the new 'hasBatteryLevel' as
another. Jose suggested this one. The example device is the SonyEricsson
p910i, once more, both because I have one, and because it's screen height
does change when the 'flip' is opened. Opening the flip also changes the
keyboard, by the way, but that's a discussion for a different property.

Screen Size
------------------

Because the screen height can change on the P910i, a single value for
'hasTotalDisplayPixelsY' in the ontology is inappropriate. Because the
height changes in response to a user opening or closing the flip on a
particular instance of the device, the DDR can't know at any point in time
the actual height of the screen. However, the DDR can know the size of the
screen with the flip closed and the size with the flip open. I've modelled
this in the ontology by changing the value associated with
'hasTotalDisplayPixelsY' from a single integer to a new class called
PixelCount. You can see the definition at [3]. I chose to use 4 values
here, based on previous debate. The maximum and minimum values, current
value and default value are explicitly represented.

A DDR could answer questions about the maximum, minimum and default
values, since these are common to every instance of the device. It can
also provide the current value IF the value can't change between different
instances of the device. In this particular example, the DDR can infer the
current value if the maximum and minimum values are the same. In the
examples within the section on PixelCount[3] you can see that the instance
'PixelCount_P920i_Total_Y' has different maximum and minumum values,
meaning that the DDR can't know the actual value on a particular handset.
It can, however, report maximum, minimum and default values. However, for
the instance 'PixelCount_P920i_X'  (and yes, there is a good reason why
the name doesn't include 'Total') the DDR could return the current value
because the maximum and minimum are the same.

A number of people have commented that not all properties necessarily need
all of these sorts of facets, and that the approach based on maxima and
minima is not necessarily appropriate for every property. I agree with
that. However, I think this example illustrates an approach that can work
for this kind of data. We may need other ways to represent other
properties.

Battery Level
-------------------

During the debate, it was also pointed out that some properties don't have
meaningful default values and may have fixed ranges, making the storage of
maxima and minima less than useful. A good example that came up is battery
level. To model this, I added a Battery class to the ontology and gave it
a couple of properties. You can see it in the document at [4]. I modelled
the capacity of the battery and its current level. The capacity is a fixed
property for a particular battery. The level is not. I confess to adding
capacity simply because it allowed me to add a new set of units of
measure, based on electric charge. It took me right back to school
Physics!

However, for this discussion, the important property is the battery level.
I chose to represent this as a floating point value between 0 and 1. Since
that range is 'baked in' to the ontology, there is no point in
representing the maximum and minimum explicitly, since it's the same for
every instance of every battery. So in this particular case, the ontology
has just a single value that represents the current battery level. Unlike
'hasTotalDisplayPixelsY', we don't need a class to represent the property.

What about the APIs?
-------------------------------

My main conclusion from this exercise is that we can model the various
situations we've identified quite easily in the ontology. I've shown a
couple of different examples. I also think the approach to handling
current value, range of possible values, and default value shown for
'hasTotalDisplayPixelsY' actually sits quite well with the DDR API. For
example, if we ask the DDR for the total number of pixels in the vertical
direction of the display for a particular device and the value can't
change, the DDR can simply answer with the value. However, if the value
can change, the DDR can return a code indicating that the value is
variable. We could then choose to ask the DDR about maximum, minimum,
default or whatever else kinds of values we might find useful.

In the case of the battery level, we might decide that there is no value
in the DDR providing such a property at all, since there is no useful
information that it can provide. The range is fixed, so we don't need to
store it. There also seems to be no value in a default value for battery
level. The overall consequence is that the ontology entry for battery
level would simply not appear in the DD core vocabulary. Rotan pointed
this out originally.

Other interfaces, that do support dynamically varying properties like
battery level, could provide such values, of course. Hence, it's important
for the property to be in the ontology.

Best wishes
Rhys

P.S The updated ontology files are also accessible from [5] and there is a
code refresh at [6]


[1]
http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/2007-05-
31/DCOntology.html
[2]
http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/2007-03-
31/DCOntology-20070331.html
[3]
http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/2007-05-
31/DCOntology.html#PixelCount
[4]
http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/2007-05-
31/DCOntology.html#Battery
[5]
http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/2007-05-
31/
[6]
http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/Code/DCO
ntology-2007-05-04.zip