RE: ISSUE-22 (Default aspect of a property): Default aspect of a property

I think the key advantage is that in some future vision we can say "what is the colourdepth of the dc" or "what is the available screenwidth of the device" when the device is the aggregate of the hardware and the current browser.

 

Jo

 

 

________________________________

From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of José Manuel Cantera Fonseca
Sent: 16 November 2007 13:32
To: Rotan Hanrahan
Cc: public-ddwg@w3.org
Subject: Re: ISSUE-22 (Default aspect of a property): Default aspect of a property

 

Hi,

So what's the advantage of having the aspect independent /separate from of the property? Why we are adopting a different approach than the ontology?

Best Regards

Rotan Hanrahan escribió: 

For the benefit of those who were not present during the discussion
today...
 
Suppose we have a property called "colorDepth".
 
This property applies to screens. It also applies to cameras. A mobile
device may have both.
 
To retrieve the right property from the DDR, we need to give it three
pieces of information:
1. The context in which the request is being made. This is the
ContextKey parameter.
2. The property to be retrieved. This is the Property parameter.
3. The aspect to which the property is applied. This is the Aspect
parameter.
 
Note, the property in question is from the vocabulary. We are not
implying that "colorDepth" is present in the ontology. Indeed, the
ontology will probably have screenColorDepth and cameraColorDepth as
separate items. You can see that in the ontology, the aspect of the
property is included in its name, and each ontology item will probably
exist within different parts of the ontology hierarchy, further
emphasising the difference in aspect. For the DDR, the property and the
aspect are considered separately.
 
getPropertyValueSet("colorDepth","screen",contextKey) would imply
screenColorDepth in the ontology.
 
getPropertyValueSet("colorDepth","camera",contextKey) would imply
cameraColorDepth in the ontology.
 
These methods are very precise about what property is intended. They
return sets because the device may have one or more screens/cameras. You
can inspect the elements of the returned set to find the screen/camera
you want. If you already know which screen/camera you want, you can use
a Component object as a parameter instead of a Property identifier,
because Component objects can be more precise.
 
However, we don't just want to provide super-powerful methods that deal
with all cases. We also want to provide the "fast food" variety, the
convenience methods that can deal with the most common use cases. These
simplified methods will "do the right thing" in most cases, and should
be appealing to those who want to take their first steps into the world
of adaptation.
 
So we want to have a method like this:
 
getPropertyValue("colorDepth",contextKey)
 
Note that this does not return a set, because we assume there is some
implementation magic that will choose the most likely component if there
are more than one. Furthermore, because colorDepth has two aspects
(screen and camera) we must also assume that the method will choose the
most likely aspect too.
 
So how does this method know that the most likely interpretation of the
parameters is "the colour depth of the main screen"?
 
We're not exactly sure about the nature of the magic that will identify
the main screen (though I suspect the ontology may help), and it's not
so clear how the method knows that "screen" is the default aspect. Where
is this information located? Is it fixed for all users of the DDR, or is
this something that can be customised? For example, if we are managing a
web-cam service, we might decide that the "camera" aspect should be the
default.
 
One possibility is that the vocabulary defines the default aspect for
each property name. This, of course, fixes the default for all users of
that vocabulary. We might simply make it implementation dependant, but
put into the vocabulary the default aspects for each property anyway,
permitting implementations to override these if necessary.
 
Whatever way the default works, if the user of the DDR API doesn't want
to use these defaults, the full-blown "five course meal" is still
available as an alternative to the "fast food".
 
On the matter of the use of Brand/Model properties, we can see how this
would also make use of aspects:
 
getPropertyValueSet("brand","platform",contextKey)
 
getPropertyValueSet("brand","browser",contextKey)
 
It now gets a little tricky to decide how to default the following:
 
getProperty("brand",contextKey)
 
Should this return something like "Nokia" or "Mozilla"? Both aspects of
"brand" are equally likely, so any default that we might defined (in the
vocabulary, for example) will only please some people, and annoy the
rest.
 
There is also the question of where these aspects are defined. Where do
we say that there are aspects called "screen", "camera", "platform",
"browser" and so on? As Jo correctly pointed out, while we could
technically include these in the DDR Core Vocabulary, it would conflate
two different concepts and cause confusion. It may be better to have a
separate vocabulary for the aspects. Perhaps these could also map to
appropriate items in the ontology.
 
We have worked hard to narrow down to a small set of classes/methods,
some of which are highly expressive and powerful, and some of which are
simplified. Hopefully the issue of aspects and defaults will not
complicate things, or ruin the good work we've done in the past few
days. Especially as we appear to have made enormous progress.
 
---Rotan.
 
 
 
-----Original Message-----
From: member-ddwg-request@w3.org [mailto:member-ddwg-request@w3.org] On
Behalf Of Rhys Lewis
Sent: 10 November 2007 19:29
To: 'Mobile Web Initiative Device Description Working Group WG'
Subject: RE: ISSUE-22 (Default aspect of a property): Default aspect of
a property
 
 
Just wanted to point out that the ontology already models default
aspects
for properties.
 
For example, display size information in pixels shows one way to model
defaults [1].
 
Best wishes
Rhys
 
[1]
http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/2007-1
0-
31/DCOntology.html#PixelCount
 
 
 
  

	-----Original Message-----
	From: member-ddwg-request@w3.org 
	[mailto:member-ddwg-request@w3.org] On Behalf Of Mobile Web 
	Initiative Device Description Working Group Issue Tracker
	Sent: 10 November 2007 18:42
	To: member-ddwg@w3.org
	Subject: ISSUE-22 (Default aspect of a property): Default 
	aspect of a property
	 
	 
	 
	ISSUE-22 (Default aspect of a property): Default aspect of a property
	 
	http://www.w3.org/2005/MWI/DDWG/Group/track/issues/
	 
	Raised by: Jose Manuel Cantera Fonseca
	On product: 
	 
	How the default aspect of a property is going to be defined?
	 
	+ Implementation dependent
	+ An spec that defines for each property the default aspect