RE: Device description structures and families

>> Yes, why not having APIs for adding families and exporting them, etc, this is an extended API not the core DDR API
 
...except there would then be a requirement in the Device Description Repository to model this 'device family' ontology. So we would need to agree that is in scope because it seems like it may be a considerable piece of work.
 
>> On a public DDR, it may be arguable to allow the definition of device families, but in a private DDR is completely possible,  and desirable, IMHO 

Yes, I agree, in fact Vodafone does just this with company-specific classifications (is it a 'Vodafone live!' device, etc.). The fact that different consumers will have different opinions on a generic family ('advanced device')  is the main reason for me thinking this is best left to a private repository or the consumer's own classification layer.
 
Cheers
Kevin

 



________________________________


	
	
	Smith, Kevin, VF-Group escribió: 

		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!
		  

	Yes, why not having APIs for adding families and exporting them, etc, this is an extended API not the core DDR API
	

		  

				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. 
		  

	On a public DDR, it may be arguable to allow the definition of device families, but in a private DDR is completely possible,  and desirable, IMHO 
	

		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 14:26:03 UTC