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

So,

PROPOSED RESOLUTION: The vocabulary will define the default aspect for 
each property. The concept of default aspect will be extensible to other 
vocabularies that other communities might produce

Can we resolve on this on monday's telco?

Best Regards

Jo Rabin escribió:
>
> 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> [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> 
>> [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 <mailto: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
>>  
>>  
>>  
>>  
>>     
>  
>  
>  
>  
>   
>

Received on Friday, 23 November 2007 10:12:00 UTC