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 12:34:47 UTC