Delivery Context Ontology (was in Device Description Definition)

Hi Jo,

I think we are moving from a discussion of the definition of the term(s) into a discussion of the ontology. That's absolutely fine, but probably on the wrong thread and also probably would benefit from a session at a forthcoming conference call where I can try and illustrate the concepts.

In brief here, the ontology covers EVERYTHING. It covers fixed properties (class properties) and dynamic properties (instance properties). It also covers validation assertions on property values.

Actually, there are specific reasons that you might want different properties for 'class' and 'instance' values, though I can't be sure this is always the case. For example, consider orientation. The property for the 'class' is an enumeration of the two possible values represented in some way. Lets assume two integer values, isPortrait and isLandscape. The class value in the ontology has to represent that enumeration. It asserts that those are the only two valid values of that property. If you ask for the instantaneous value and receive isFaceDownInAPuddleOfWater, you know its an error. Actually, the implementer of the interface knows its an error and presumably does something appropriate.

A more interesting example might be bluetooth profiles. The class entry for the device might contain the enumeration of the profiles that the device can support, while the instance value contains the one currently active.

Hope that helps. 

On the white swan issue, extensibility of the ontology is an important topic that we will probably have to debate. Remember though that in the context of DDWG, we will be defining the scope of the repsitory interfaces, presumably based on the results of the top-N discussion. So the problem for us is, at least initially, bounded. 

Also, there are extensibility models in existence for vocabularies. OMA operates one for UAProf.

Best wishes
Rhys





-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin
Sent: 01 March 2007 15:03
To: Rotan Hanrahan; public-ddwg@w3.org
Subject: RE: Device Description definition


OK I think I am getting closer to my understanding what you are saying, and hopefully vice-versa :-)

What I still don't understand is why you would want to have a different named property for instances than you do in the type, or class definition (in the example, permitted orientations vs. actual orientation).

The logic seems to me to be something along the lines of:

The ontology defines the properties you can talk about, the facets of those properties and the value space attached to the facets. 

A class definition refines the ontology, in a premeditated way, for a class of devices that share important features (like their manufacturer name and model number and version), and collapses the value spaces for the facets into actual lists or ranges of permissible values of properties for instances. Often this will result in a single value (e.g.
width). Sometimes it will result in a list (landscape, portrait).
However the fact that this is a list is just as much a shared property characteristic of what is being described as if it were a single value.

As I see it a class definition is an ontology which is necessarily a proper subset of the overall ontology. And it is the class definition ontology that the device chooses actual values from.

An instance definition, on the other hand, is not an ontology. It's a collection of properties and actual values - i.e. a statement constrained by the device class ontology, itself constrained by the overall ontology.

So here again, the device class ontology says you can make a statement about screen orientation and the allowable values are landscape and portrait.
 
Moving on to the notion of sets: If you want to compose a set based not on some premeditated idea of a device, but some shared property value, then surely you do this at the class definition level. You might compose a set of Default Delivery Context [DDC] compatible devices by noting all the class definitions in which the screen width was 120 pixels or more.

The problem with creating a class definition from instance values is surely that the ontology can rapidly become broken - e.g. all swans are white until you discover Australia when you suddenly discover that whiteness is not after all an immutable property of swans. 

And equally, the fact that a property is immutable (i.e. can have only one value) is no more a distinguishing feature than that a property is constrained to two values (from 9 for example).

[I now have to attend a BP call, so I will stop!]

Jo





> -----Original Message-----
> From: Rotan Hanrahan [mailto:rotan.hanrahan@mobileaware.com]
> Sent: 01 March 2007 14:31
> To: Jo Rabin; public-ddwg@w3.org
> Subject: RE: Device Description definition
> 
> By immutable I mean that the value can be assigned once, and when that 
> value is known it will remain unchanged. Typically, the physical width 
> of the screen is an immutable property. We could then refer to the set 
> (or class) of devices that have a particular screen width. In other 
> words, the definition of the set includes the fact that the devices
have
> a ScreenWidth property, and that the property has a particular value.
> 
> We could further add a longer set of similarly immutable properties 
> until we eventually identify something we would recognise as a 
> particular model of a device from a particular manufacturer. This is
the
> level of identification that I believe will be most common, but I do
not
> preclude other possible set membership definitions.
> 
> The tie-in between the "device type properties" and the "device
instance
> properties" in the example I gave relates to the data types used to 
> describe the permitted and current screen orientations. If I use a 
> number to represent orientation, then it is wise that we agree on what 
> the numbers mean. Consider a slightly more complex example of an 
> immutable property: "The set of permitted orientations and the default 
> orientation". It is clear that within this complex type we should
ensure
> that "default orientation" is a subset of "permitted orientations".
Now,
> how do we ask the question: "is the screen currently in the default 
> orientation?". For such a question to be formulated programmatically,
it
> is necessary to ensure that the data types are comparable. This is
best
> achieved by using essentially the same data types. (It avoids the need 
> for translation.)
> 
> This is why it is sensible to work closely with other groups (like the 
> DCI group within the DIWG, and the groups from the OMA). By keeping
our
> data types, vocabularies, ontologies (etc.) in harmony, we can help 
> avoid future compatibility issues.
> 
> The way you are formulating the ontology/type-def/instance seems to 
> capture this idea.
> 
> > If the class allows only one value, the property is immutable.
> 
> The value may in fact belong to a collection type. So a particular set 
> of permitted orientations would be an example of the only value
allowed
> for a property. That property we may call "PermittedOrientations".
There
> is a second atomic property which has a value from the set value 
> assigned to PermittedOrientations, and this one we will call 
> CurrentOrientation. This latter value may vary. Each device in the set 
> of devices will have such a property, but the value of the property
does
> not form part of the definition of the set. (The fact of *having* such
a
> property *may* form part of the definition of the set.)
> 
> "Class" would work fine for me.
> 
> ---Rotan.
> 
> -----Original Message-----
> From: Jo Rabin [mailto:jrabin@mtld.mobi]
> Sent: 01 March 2007 14:07
> To: Rotan Hanrahan; public-ddwg@w3.org
> Subject: RE: Device Description definition
> 
> My comments in line:
> 
> > -----Original Message-----
> > From: Rotan Hanrahan [mailto:rotan.hanrahan@mobileaware.com]
> > Sent: 01 March 2007 13:02
> > To: Jo Rabin; public-ddwg@w3.org
> > Subject: RE: Device Description definition
> >
> > The DI glossary describes a device as an "apparatus". The dictionary 
> > would seem to allow both physical and non-physical examples.
Therefore
> I
> > think Jo is correct that the mention of "hardware and software" is 
> > redundant. But this might just be an example of "DI Lore and
Wisdom",
> > and perhaps to the casual reader this subtlety may go unobserved.
> >
> 
> Sorry, I should have been clearer in my citation (from
> http://www.w3.org/TR/di-gloss/)
> 
> Device
>     An apparatus through which a user can perceive and interact with
the
> Web.
> 
> User Agent
>     A client within a device that performs rendering.
>     Browsers are examples of user agents, as are web robots that 
> automatically traverse the web collecting information.
> 
> Client
>     The role adopted by an application when it is retrieving and/or 
> rendering resources or resource manifestations.
> 
> So I infer that a user agent is a client (which is an application)
which
> forms part of a device which is an apparatus.
> 
> [As a side note, I see that robots are user agents, which are clients
in
> a device. Which would lead you to infer that a robot is part of an 
> apparatus through which a user can perceive and interact with the Web.
> Which I think is only arguably true.]
> 
> > In which case, there is an argument for revising the DI definition
of
> > Device to add such a clarification.
> 
> I think I agree.
> 
> >
> > Not all of the properties of a specific device are the territory of
> some
> > other group. A specific device may belong to a class of device (a
set
> of
> > devices) defined according to having the same value for some
immutable
> > property.
> 
> Right, I think this is where my confusion sets in. I can see what you 
> are saying, I think, but surely the important thing is that the 
> attributes that are immutable, as you call them, are only immutable 
> because the device is of a type where there is only one value that an 
> instance of the device can have for that attribute.
> 
> If the device type definition says 'screen width: 120' then all 
> instances have an immutable property of screen width 120.
> 
> 
> Those immutable properties are clearly the kind of data of
> > interest to this group. Properties that may vary, on the other hand,
> are
> > the territory of other groups.
> >
> > A device may have the ability to display in two orientations:
> landscape
> > and portrait. This ability is an immutable property of the device.
> >
> > At a particular point in time, a specific device may be rendering in
> one
> > of the two orientations. The orientation in use may vary over time.
> This
> > property is not something that can be managed by a repository.
> >
> > In the example, we are dealing with two related properties:
> >   Permitted Orientations
> >   And
> >   Current Orientation
> 
> I don't think I quite see it that way. It doesn't seem to quite tie 
> together the device type properties with the device instance
properties.
> 
> 
> It seems to me that it [could] work like this:
> 
> - the ontology says that there is an attribute called screen
orientation
> that has a value space of landscape and portrait.
> - the device type definition says this device type has screen 
> orientation landscape or portrait
> - the instance says it has landscape (for example)
> 
> i.e. the device type definition contains permissible values for the 
> attributes and the device instance has actual values for _the same_ 
> attributes.
> 
> So back to the example above,
> - the ontology says screen width is an integer (ignoring facets, just 
> for a moment)
> - the device type definition says screen width is 120
> - the device instance definition therefore necessarily says screen
width
> is 120
> 
> >
> > If you indicate a set of immutable properties, and values for those 
> > properties, then you can define a set of devices as all those
devices
> > that have those particular values. This was the "set" concept I had
in
> > mind in the definitions I have suggested recently.
> 
> But, the fact that the screen orientation can be either landscape or 
> portrait is a shared property of all devices in a class, even though 
> their instances may have different property values to each other. I 
> think my confusion crucially rests on the point that I think instance 
> attributes are the same as type (or class) attributes. So to me 
> immutable properties are neither here nor there. If the class allows 
> only one value the property is immutable.
> 
> >
> > To answer another of your questions: I think it is the attributes
and
> > their range of values that characterise a device. In this, I also
> would
> > permit the value "Not Applicable" (distinct from "Not Known", which
is
> > another issue entirely).
> 
> Yes, agree strongly - but this is a feature of the ontology, surely, 
> which would allow either of those as a value for any attribute?
> 
> >
> > I'm a bit worried about the use of the word "type". I'll have to
think
> > more about it.
> 
> Would class work better for you?
> 
> Jo
> 
> >
> > -----Original Message-----
> > From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org]
> On
> > Behalf Of Jo Rabin
> > Sent: 01 March 2007 12:35
> > To: public-ddwg@w3.org
> > Subject: RE: Device Description definition
> >
> >
> > I am running along behind on this ... trying to keep up, forgive me:
> >
> > Commenting on: "Device Description - A set of attributes which 
> > characterizes that part of the delivery context directly related to
> the
> > hardware and software of a device. These attributes adhere to the 
> > Delivery Context Ontology."
> >
> > I thought a device, as defined by DI, is hardware and software?
> > Specifically it includes the user agent. So what point are we making
> by
> > saying 'related to the hardware and software of a device' that is 
> > different to saying 'relating to a device'?
> >
> > A further confusion, on my part, is that when we say 'a device' we
> don't
> > mean 'a specific device', because as discussed (accidentally on the 
> > other list, I think) the exact values for the properties of a
specific
> > device at a point in time is the territory of some other group. So
do
> we
> > in fact mean 'devices' or better still 'classes of devices' or
perhaps
> > better even than that 'type of device'?
> >
> > My next confusion is - is it the attributes that characterise the
type
> > of device, or is it the attributes and their possible values that 
> > characterise the type of device?
> >
> > And as a possibly rather pedantic kicker, when we say 'set', do we
> mean
> > that the same set is chosen for all device classes or do we mean,
more
> > loosely, that it is a collection of attributes - some of which may
be
> > present for some descriptions but not others?
> >
> > So if I am heading down a track that is comprehensible to anybody,
do
> we
> > mean:
> >
> > Device Description - a collection of attributes chosen from the
> Delivery
> > Context ontology, together with the values for those attributes that 
> > characterise a type of device.
> >
> > Thanks
> > Jo
> >
> >
> > > -----Original Message-----
> > > From: public-ddwg-request@w3.org
[mailto:public-ddwg-request@w3.org]
> > On
> > > Behalf Of Rhys Lewis
> > > Sent: 01 March 2007 12:08
> > > To: Rotan Hanrahan; Smith, Kevin, VF-Group; public-ddwg@w3.org
> > > Subject: RE: Device Description definition
> > >
> > >
> > > Hello everyone,
> > >
> > > I think we are making progress!
> > >
> > > One comment is that 'they' are not attribute/value pairs. T think
we
> > > should simply refer to 'them' as attributes, which is the term
from
> > the
> > > delivery context definition.
> > >
> > > Also, I think we should use the term ontology rather than
> vocabulary.
> > We
> > > probably should also define a term like Delivery Context Ontology
> > (I'll
> > > volunteer to suggest a definition) and then refer to that from the 
> > > definition for device description.
> > >
> > > That would lead to something like:
> > >
> > > Device Description - A set of attributes which characterizes that
> part
> > of
> > > the delivery context directly related to the hardware and software
> of
> > a
> > > device. These attributes adhere to the Delivery Context Ontology.
> > >
> > > I tweaked the wording to match that from the delivery context
> > definition.
> > >
> > >
> > > Best wishes
> > > Rhys
> > >
> > > -----Original Message-----
> > > From: public-ddwg-request@w3.org
[mailto:public-ddwg-request@w3.org]
> > On
> > > Behalf Of Rotan Hanrahan
> > > Sent: 01 March 2007 11:19
> > > To: Smith, Kevin, VF-Group; public-ddwg@w3.org
> > > Subject: RE: Device Description definition
> > >
> > >
> > > I like this definition. Good body, delicate nose, hint of oak...
> > >
> > > We should view this proposal in the context of the DI Glossary
[1].
> > The
> > > important terms there are Device and Delivery Context. It seems to
> me
> > that
> > > the "mash-up" fits well with these existing definitions.
> > >
> > > ---Rotan.
> > >
> > > [1] http://www.w3.org/TR/di-gloss/
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: public-ddwg-request@w3.org
[mailto:public-ddwg-request@w3.org]
> > On
> > > Behalf Of Smith, Kevin, VF-Group
> > > Sent: 01 March 2007 11:14
> > > To: public-ddwg@w3.org
> > > Subject: RE: Device Description definition
> > >
> > >
> > > How about a mash-up? Definition 2.0, as it were:
> > >
> > > Device description - a collection of attribute-value pairs,
adhering
> > to a
> > > known vocabulary, that apply to each member of a set of devices
and
> > > describe the specific part of the delivery context directly
related
> to
> > the
> > > hardware and software of the device.
> > >
> > > Kevin
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Rotan Hanrahan [mailto:rotan.hanrahan@mobileaware.com]
> > > Sent: 01 March 2007 11:09
> > > To: Smith, Kevin, VF-Group; public-ddwg@w3.org
> > > Subject: RE: Device Description definition
> > >
> > > The most recent one that I posted to the public list was actually:
> > >
> > > Device description - a collection of attribute-value pairs,
adhering
> > to a
> > > known vocabulary, that apply to each member of a set of devices.
> > >
> > > This incorporates the point made my Rhys regarding ontology
> > (vocabulary)
> > > though does not specifically mention Delivery Context, which I
think
> > might
> > > be a good idea. Suggestions anyone?
> > >
> > > ---Rotan.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: public-ddwg-request@w3.org
[mailto:public-ddwg-request@w3.org]
> > On
> > > Behalf Of Smith, Kevin, VF-Group
> > > Sent: 01 March 2007 11:05
> > > To: public-ddwg@w3.org
> > > Subject: RE: Device Description definition
> > >
> > >
> > > Hi everyone,
> > >
> > > So (I think) the latest proposal for the definition was from Rhys,
> > > namely:
> > >
> > > Device description: describing that specific part of the delivery
> > context
> > > directly related to the hardware and software of the device.
> > >
> > > ...where delivery context is defined as "A set of attributes that 
> > > characterizes the capabilities of the access mechanism, the
> > preferences of
> > > the user and other aspects of the context into which a web page is
> to
> > be
> > > delivered." This (to me) covers Jo's point about current and
> possible
> > > values.
> > >
> > > Alternatively we have Rotan's defintion:
> > >
> > > Device description - a collection of attribute-value pairs that
> apply
> > to
> > > each member of a set of devices.
> > >
> > > Are there any further comments on either? I personally think both
> are
> > > correct, but that it makes sense to associate the definition with
> the
> > > delivery context as per Rhys' wording.
> > >
> > > Cheers,
> > > Kevin
> > >
> > >
> > >
> > >
> > >
> >

Received on Friday, 2 March 2007 08:42:06 UTC