RE: Delivery Context Ontology (was in Device Description Definition)

Hi Jo, 

This could become a philosophical discussion. I think you are saying that when you ask for bluetooth profile, if you get an enumeration, you know these are the allowed values, whereas if you get a single value you know it's the value. Let me apologise in advance if I've got that wrong. What follows is based on that assumption.

I suspect that the knowledge representation community would start scowling at this point. The set of allowable bluetooth profiles is not the same information as the actual profile applying to a particular instance of a device at a particular instant in time. In RDF terms it requires a different URI.

It seems to me that your suggestion effectively hides the fact that these are fundamentally different things. They become distinguishable only through agreed semantics on the interface. Every interface has to implement those particular semantics, or risk confusing their users. Some interface implementations may simply not be able to support those semantics.

Practically it also happens to complicate the implementation of the interface itself and the code that uses it, but that's a secondary point. (I'm probably just excessivly bitter at the moment after the experience of trying to learn the Protégé OWL APIs!)

Of course, this may be moot anyway, since DDWG interfaces only ever return the 'possible' value(s). You CANNOT ask for the 'is' via the DDWG interface, because it has a fixed repository behind it. 

To get the 'is' you will need to use the OMA DPE interface, server side, or the DCI, client side. One reason for the ontology is to try and keep these three interfaces consistent.

By the way, your use case is not really typical of the content adaptation space, at least in my experience. There, queries are almost invariably made with unambiguous knowledge of the device for which the values are required.

Best wishes
Rhys





-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin
Sent: 02 March 2007 09:22
To: public-ddwg@w3.org
Subject: RE: Delivery Context Ontology (was in Device Description Definition)


Hi Rhys

Thanks for this which is, as usual, illuminating. I think a discussion on the next call would be most helpful. However, we have only a scant hour on the calls, and other business to transact, so forgive me if, in advance of that I try to put my point (or confusion, whichever you
prefer) to allow that discussion to be a little less ab initio.

To my way of thinking, a device description (Device Class Description), in the sense in which we mean it (an object that can be stored, retrieved by query and so on, from a Device Description Repository) is an ontological object. That's to say that the relationship between attributes and their values is a 'can be' relationship. By contrast the relationship between the attributes and their values in a Device Instance Description is 'is'.

Consequently I find it very hard to discuss the definition of device description without reference to ontology, because the type of device description we are interested in _is_ an ontology, necessarily a sub-set of the overall Delivery Context Ontology.

I don't think the definition of the distinction between fixed properties
(class) and dynamic properties (instance) is quite right - at least not according to this perspective.

In a typical use case, I know some attributes and their values from a particular Device Instance Description, and I want to find out more. So I query the DDR with those attributes and it returns me a (set of) device descriptions that match. In many (but not all) cases I will get just one, particularly if I choose the attributes to be User Agent String and UA Profile from the HTTP headers.

The DDR matches those parameters on the basis that for only a limited subset of its descriptions the 'can be' relationship is true.
Particularly in the case where the 'can be' has one and only one value, in which the relationship becomes stronger - viz 'can be and must be'.

Now I want to know the screen width in pixels of the requesting device.
The device class description contains a single value. i.e. it is a fixed property. The instance description can only contain that value so I don't need to do anything else. It's a fixed value that I have determined from the class definition.

Next I want to discover the Bluetooth profile. The Device Class Description contains a list of possible profiles. So I know that I need to do more to find out what the value of that attribute _is_ in the Device Instance Description.

In this view of the world the Device Class Description and the Device Instance Description have the same named attributes. It is the data types that are associated with the attribute that are different to reflect the differing semantics of 'can be' and 'is'. The first allows an enumeration, range or whatever, the second does not. 

I hope this clarifies my point and that it does indeed contribute to the discussion of 'what is a device description' rather than 'what is the nature of the device description ontology'.

Jo

> -----Original Message-----
> From: Rhys Lewis [mailto:Rhys.Lewis@volantis.com]
> Sent: 02 March 2007 08:41
> To: Jo Rabin; Rotan Hanrahan; public-ddwg@w3.org
> Subject: 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 10:02:27 UTC