Re: Device description structures and families

This is very near to what I thought about families.

There are two cases that José described that I don't understand if  
are matched in your proposed solution.

First of all is the ability for a DDR to communicate with the  
querying individual the structure and definition of a family. This  
would imply that the DDR is also able to store locally at least the  
definition of the family. Processing can happen at the request time  
or stored.

The ability to determine if a device is part of a family. Would this  
require the querying individual to also re-state the family definition?

- Andrea



Il giorno 22/mar/07, alle ore 11:17, Rafael Casero ha scritto:

> Hi all,
>
> I think there was a somewhat similar problem at OGC (Open  
> Geospatial Consortium) and maybe its solution can be useful for us  
> too. In order to explain the similarities (and then the approach)  
> let me first summarize a little bit our problem.
>
> a) There are some 'static' device properties, for instance, screen  
> width
>
> b) There are, also, some other properties 'derived' from the  
> 'static' ones: we can say that belonging to a particular family is  
> the result of applying a 'formula', for instance,
> (XHTML-MP = yes) AND (width > 128)  AND  (height > 160).
>
> In such a view, the 'family' semantics is the result of applying a  
> formula (or pseudocode) . The way in which that is implemented in a  
> real DDR need not to be specified: it can be evaluated on demand or  
> can be previously evaluated and stored (like any 'static'  
> property), that will depend on the particular implementation.
>
> The similar problem that OGC found is that they have 'features'  
> that are 'static' properties related to a particular location  
> (i.e., there is a petrol station at location x, y). For that they  
> defined the 'Web Feature Server' (WFS) that it is a minimum set of  
> specifications that a server must comply. Also they have a  
> specification for a 'Web Processing Server' (WPS) that allows for  
> 'derived' properties or calculated results (i.e., give me the  
> petrol stations inside the area defined by xMin, yMin, xMax, yMax).  
> They separate both specifications because the processing required  
> in the second case can be much demanding than in the WFS case.
>
> Translating this specification to our case will be something like  
> this:
>
> a) Families can be defined as a formula or a pseudo-code
>
> b) DDRs could have processing capabilities or not
>
> c) DDRs, with processing capabilities, could store formulas (or  
> code) as a way to define families. The way in which they are solved  
> and processed (on demand, previously stored, etc.) depends on the  
> particular implementation allowing for a quality of service  
> differentiation between providers
>
> d) Different families can be defined for different companies using,  
> for instance, name spaces. Then there can be also a business case  
> for the families definition (effective terminal segmentation)
>
> e) Privileged users could be able to define 'derived  
> properties' (i.e. families) by defining the name (within a name  
> space) and the formula (or pseudo code)
>
> f) Developers could define the 'formula' to apply in the query or  
> (depending on their privileges) store it as a 'derived property'
>
> g) Effective terminal segmentation (families) can be offered by  
> some providers by defining particular formulas.
>
> h) Developers can query for a 'static' or 'derived' property in the  
> same way transparently, only, maybe, they have to query to a  
> different DDR depending on the property queried. (Also there is  
> here a business case: the DDRs that can deliver 'derived'  
> properties can offer to their customers processing capabilities and  
> good semantics)
>
> This figure is like to mimic the OGC way of doing. Of course we  
> have to discuss if that model is of any use for us but I think is  
> worth to think at it.
>
> What do you think about it?
>
>
> - Raf.Casero
>
> -------- Mensaje Original --------
>> Hi all,
>>
>> I have started with some use cases regarding device description  
>> structures [1]. Two of them are envisaged but not yet written :).
>>
>> You are welcome to contribute with more use cases, like those that  
>> Kevin and Andrea has mentioned these days in the list.
>>
>> Feedback from the public and group members is also needed
>>
>> Thanks and best regards
>>
>> [1] http://www.w3.org/2005/MWI/DDWG/wiki/ 
>> DeviceDescriptionStructuresUseCases
>>
>> Rotan Hanrahan escribió:
>>>> This would assume a common syntax for representing the family  
>>>> rules.
>>>>
>>> And this is precisely where I think the work that José is leading  
>>> will help us.
>>>
>>> ---Rotan
>>>
>>> -----Original Message-----
>>> From: Smith, Kevin, VF-Group [mailto:Kevin.Smith@vodafone.com]
>>> Sent: 20 March 2007 15:48
>>> To: Rotan Hanrahan; public-ddwg@w3.org
>>> Subject: RE: Device description structures and families
>>>
>>> Hi Rotan,
>>>
>>> Thanks for the clarification...
>>>
>>> Another use case is content filtering, e.g. indicating that 'this  
>>> family gets a movie, while this family gets an image'. Resolution  
>>> of the expression would involve confirming the requesting device  
>>> is of a given family. Then the appropriate link or object would  
>>> be presented.
>>>
>>> As both yourself and José say, there could be benefit in sharing  
>>> some of these family classifications: for example, a games  
>>> publisher could create a set of rules as to which devices can  
>>> support their latest games for the best user experience (mature  
>>> J2ME, good CPU, decent resolution etc.) and this could be  
>>> represented as a family (possibly namespace bound, eg  
>>> gamescorp.bestSupport). They could also provide minimum criteria  
>>> for legacy games (gamescorp.justSupport). Maybe the provisioning  
>>> of these family rules can be in a DDR extension, or it could be  
>>> possible in the query to the DDR to ask for the family rules to  
>>> be fetched from an external source (such as gamescorp  
>>> themselves). This would assume a common syntax for representing  
>>> the family rules.
>>>
>>> Cheers
>>> Kevin
>>>
>>>
>>>
>>>
>>>
>>>
>>> [...]
>>>
>>>
>>>
>>