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.