RE: Device description structures and families

> The fact that the DDR will allow Actors to query device properties from a single trusted source is (to me) the big advantage, and is the major change from the current solutions. I'm just not sure that we can also expose a set of arbirtary and volatile groupings on top of the static properties in the DDR.

While we are working towards a common API, we have not actually mandated that the properties come from a single trusted source, or even that the DDR will be a singleton. Indeed, for scalability reasons, a distributed mechanism is suggested. However, it is among our requirements to be able to determine if the information originated from a trusted/verified source. From an end-user point of view, I would like to be able to access any information held in the publicly accessible DDR from a single access point. This is similar to my expectation regarding DNS resolution, wherein I can have a single access point to make any query I like regarding DNS, assuming my DNS server will forward requests for data it does not itself possess. When I get a response, I can easily determine if it is authoritative or not, and if it is cached then I can tell how old it is.

In the case of the DDR, I expect similar capability at a minimum. However, I may also wish to qualify my query so that I can insist that only trusted sources are accessed.

For the basic DDR use case, I expect to provide sufficient information in my query to identify a device, and then to get a response associated with the identified device. For me, this is the core behaviour.

The situation described by José is different. In this case I am not identifying a single device, I am identifying a class (family) of devices. I am not sure what kind of queries I might make that involve device families, in the field of content adaptation. Perhaps you are doing pre-adaptation: "give me a list of all smartphones with 240px wide screens so I can make content for them."

Either way, I'd like to see the detailed use cases to understand who defines the classification (families), if and where such definitions are stored, and how/why I would share these with other users. Like you, Kevin, I wouldn't want anything to impact the stability of the DDR itself, and this would include volatile groupings. However, I would be quite happy to see an external agency handling the groupings, and if they want to use OWL, that's fine. If they are described as an extended DDR, or a DDR extension, or whatever, that's also fine. I see such things as families, groups etc as just more sophisticated ways of constructing queries. If my sophisticated query construction is of use to others, then I can see a value in being able to share my definitions, which is perhaps what José is describing.

Finally, just to point out that this is just the start of the discussion on "structures" in the DDR, so nothing is agreed or defined yet. We are just having a "healthy" debate :)

---Rotan.

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Smith, Kevin, VF-Group
Sent: 20 March 2007 12:34
To: public-ddwg@w3.org
Subject: RE: Device description structures and families


Hi José,
 
>> It is agreed that we are not going to mandate families, we are going to provide an informative note on how to do this, and how it can be shared different families within a community or an organization

I'm missing something here: if the "the DDR can store the definition of the family devices by means of OWL" then who will populate that OWL, i.e. who will decide what device is in what family? Because we are saying it won't be us...if it's open for anyone to define, then that implies conflict resolution, public APIs to update etc. Sorry if I'm misunderstanding!

>> Your solution sounds to me as leaving things as they are done currently in different open source and propietary solutions. The advantage of defining standard mechanisms for creating abstractions related to groups of devices is the possibility of sharing things and not confuse developers with different conceptions or mechanisms

The fact that the DDR will allow Actors to query device properties from a single trusted source is (to me) the big advantage, and is the major change from the current solutions. I'm just not sure that we can also expose a set of arbirtary and volatile groupings on top of the static properties in the DDR. 

Cheers
KEvin



________________________________

	Smith, Kevin, VF-Group escribió: 

		 
		Hi José,
		
		Thanks for moving this to the public list.
		
		  

				José: There is no need to query an external source, the DDR can store the definition of the family devices by means of OWL
				      

		
		I agree that's technically possible, and I can see that working for a case where a Repository Provider builds and manages their own private repository. 
		
		But for a public DDR, is this not the same as (1)? It would mean an extra maintenance step (creating all the families, updating them for new devices) and an extra body of work in the DDWG to mandate what the families are (please correct me if I misunderstand). Then, of course, any users of the DDR may disagree with the criteria which define a given device family.
		  

	It is agreed that we are not going to mandate families, we are going to provide an informative note on how to do this, and how it can be shared different families within a community or an organization
	

		  

				José: A change in the filtering conditions results in a recompilation of the source code. 
				      

		
		Not necessarily, one can provide runtime parameters, or implement dynamic queries based on GUI input, for example. I'm guessing there must be other ways too?
		
		  

	Your solution sounds to me as leaving things as they are done currently in different open source and propietary solutions. The advantage of defining standard mechanisms for creating abstractions related to groups of devices is the possibility of sharing things and not confuse developers with different conceptions or mechanisms
	

		Cheers,
		Kevin
		 
		
		
		________________________________
		
			From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of José Manuel Cantera Fonseca
			Sent: 20 March 2007 11:06
			To: public-ddwg@w3.org
			Subject: Device description structures and families
			
			
			Hi all,
			
			This is a summary of a discussion that started on the member list. The discussion has to do with the definition of device families to support content adaptation or other scenarios. The DDWG is chartered to produce a note regarding this issue. The options for supporting device families are: 
			
			---
			
			1) have belongsTo(family(ies)) as an explicit property in the DDR and maintain the device family classifications within our ontology
			
			- this will be unachievable as there could be a cartesian product of families based on all combinations of properties. Alternatively we mandate properties, but as Andrea says, this would be a 'best guess' and would require an operational process to introduce more.
			
			2) have belongsTo(family(ies)) as an explicit property in the DDR and point to another classification schema as the criteria source. The suggested classification schema is OWL. (Jose) The advantages of using OWL are:
			
			+ A higher level of abstraction and improved maintenance (I don't
			imagine spreading all over the source code the condition 'XHTML-MP +
			width > 128 + height > 160') 
			
			+ The portability and reuse of common device families between an
			organization or a community
			
			+ The possibility of using tools like Protege for defining device
			families
			
			+ The possibility of exploiting all the semantic web axioms
			(equivalency, sameAS, etc) in defining device families. 
			
			+ A better alignment with the delivery context ontology
			
			- This is better than (1), although Kevin worried that we then need to define a mechanism for modelling and querying this external source. 
			
			Jose:  There is no need to query an external source, the DDR can store the definition of the family devices by means of OWL
			
			3) have the logic at the consumer end (by consumer I mean whoever queries the DDR). So for example a convenience global variable in the language that is performing the query could wrap all the query criteria that make up the device family. 
			
			Pseudo-pseudocode:
			$advanced-device = "supportsXHTML-MP AND hasPixelWidth > 128 AND hasPixelheight > 160)"
			
			If DDR.query('$advanced-device')=true
				# include advanced markup
			
			
			Then the consumer is free to vary the criteria of their device family at will (e.g., what they define as a 'advanced' device now will surely be different in 2009, and will likely differ between consumers at the same time). I guess Andrea will explain a 'developer defined device family' approach a lot better in his document
			
			Jose: This mechanism could not be very maintanable in languages such as Java. A change in the filtering conditions results in a recompilation of the source code. That's why Jose is proposing supporting options 2 and 3.

Received on Tuesday, 20 March 2007 15:02:39 UTC