RE: Device description structures and families

Yes, the Vodafone example was just to illustrate that a family can be represented by a Boolean property, *assuming* a (usually human) certification process has been run to determine the value. So not the only way to do it, but I suspect others may wish to provide a pre-built family classification (the aforementioned gamescorp:bestSupport, for example).
 
If we don't allow open queries then at  least users wishing to perform complex queries could perform a periodic batch download of the DDR and use their own query layer.
 
Andrea, I see what you mean about views, but they are not arbritrary: the DBA would need to know the criteria (or at least the properties) in advance, which he would not for arbritrary queries...closest I can think of is a dynamic stored procedure, but again there would be so many permutations of query that it would be impossible to maintain. 
 
Having said that, I can see views providing efficiency for each of the Top N properties (assuming they are non-numeric or  unconstrained String)
 
NB Are views just specific to RDBMS? So far I've kept the DDR requirements at a high enough level to allow any kind of repository (LDAP, any XML DB), so if views are RDBMS only we could be forcing an implementation.
 
Also are we saying that an open query is anything with more than one selection critera (i.e., an AND in SQL).
 
Cheers
Kevin


________________________________

	From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Andrea Trasatti
	Sent: 26 March 2007 10:43
	To: public-ddwg@w3.org
	Subject: Re: Device description structures and families
	
	
	It seems to me like the Vodafone approach is an approach that works at company-level only. I might care about VLive, but I might not. The DDR approach suggested here is much broader. 

	I think that a first level of discrimination could happen at the user permissions level. As a DDR admin I could allow some users to run "open queries" or I might not, for example. Trusted users (or paying users) might have access to this, while some other groups of users might not.

	Is this really where José wanted to go? Is this where the group wants to go?

	Vodafone's approach is "I get a human down to check, if a device meets X,Y,Z requirements it's marked with a boolean value", that's OK, and works good for them. Allowing random queries can easily kill a DDR. But what if we build views? There could be the admin of the DDR defining the views and thus the families. The users will be allowed to request for the devices that make up the family.
	I thought this was what José wanted and not the ability to run random queries on the DDR. I might be wrong, of course.

	Do we really want to have open queries in the default implementation? Sounds a lot like an extra feature that someone might want to add (maybe as part of a premium service) and some are not so interested in providing.

	- Andrea


	Il giorno 26/mar/07, alle ore 11:06, Rotan Hanrahan ha scritto:


		

		The well-formedness requirement is insufficient to determine the performance behaviour of an expression. I am particularly concerned with the possible use of regular expressions, because a well-formed regex can be massively inefficient simply because it is designed badly. A bad design is not detectable (for a deeper understanding refer to work on Deterministic Finite State Automata, NP-completeness of back reference matching etc.). In effect, you cannot automatically predict the likely behaviour of an uncontrolled query.

		

		Of course, one can work around some of these deficiencies using quota. For example, you may permit a query to execute for no more than 5 seconds, at which point it is abandoned. Repeated quota-reaching requests from the same source are eventually rejected immediately, thus avoiding DoS attacks and other resource-wasting issues.

		

		But I know (from painful experience) that some regex implementations cannot be aborted (cleanly, or at all), so I can see implementers having some problems.

		

		Even without regex, queries can cause massive problems. Ask any SQL DB designer about query tuning...

		

		As for the use of Booleans, I assume that one of the following was used to determine the values of the Booleans:

		- A human examined the data space and determined from the existing values what the Boolean value should be.

		- A pre-determined expression over the available variables was evaluated to get the Boolean, which is then cached.

		

		So, the only difference is that in the Vodafone case the process is done in advance, whereas in recent dialogue we have been talking about the process taking place in real-time (at the time of query).

		

		We've had multi-conditional support in our adaptive technology for many years, and it can be supported in the recent DISelect (from the DI group), so it's not an unusual run-time requirement. In our own experience/products, the query and the source of information are under common control, whereas in the case of the DDR the source of the query and the place of control are separate.

		

		I think we need to look very carefully at this.

		

		---Rotan.

		

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

		

		I can only answer from my own Vodafone experience, where we do use device families - however membership of these is usually represented by a single, static Boolean property (isAdvancedDevice=true, isVodafoneLive=true, etc.).

		We sometimes make much use of multi-conditional queries, but these will typically involve a dynamic property (e.g. hasMarkup=XHTML-MP and hasBearer=3G).

		

		So my opinion is:

		- the interface must allow arbritrary, multi-conditional queries (with efforts to prevent Denial of Service or slow performance, such as having a validation step when receiving a query at the interface and rejecting anything badly-formed)

		- that pre-built classifications should be allowed in the repository to indicate membership of a namespace-bound family.

		

		Cheers,

		Kevin

		

		

		

			

			
________________________________


			From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Rafael Casero
			Sent: 24 March 2007 18:21
			To: public-ddwg@w3.org
			Subject: Re: Device description structures and families

			In fact that is the reason why there is a different specification for a server accepting queries related to static features and a server accepting queries that requires processing.
			
			I do not know exactly how the real implementations of a processing server are but I know that they have mechanisms for rejecting demanding users or queries.
			
			If there are developers wanting to use the functionality, maybe there are providers willing to offer it. Maybe what we have to do is study if there are real needs for user defined families (or grouping)
			
			Raf.Casero
			
			-------- Mensaje Original --------

			I have a practical concern regarding the use or arbitrary query expressions (e.g. expressions that define family membership). It is certainly possible to construct expressions that have a very heavy processing load, as any SQL DB administrator will confirm. An expression involving, say, poorly constructed regular expressions, could tie up a processor for a considerable time. This places a serious and unpredictable burden on the provider of a DDR that supports arbitrary query expressions.
			 
			The risk is both from deliberate denial-of-service attacks, and accidental use of ill-conceived expressions.
			 
			I would be interested to know how the integrity and availability of a DDR could be maintained in these circumstances.
			 
			---Rotan.
			 
			-----Original Message-----
			From: public-ddwg-request@w3.org <mailto:public-ddwg-request@w3.org>  [mailto:public-ddwg-request@w3.org <mailto:public-ddwg-request@w3.org> ] On Behalf Of Rafael Casero
			Sent: 23 March 2007 14:06
			To: Andrea Trasatti
			Cc: public-ddwg@w3.org <mailto:public-ddwg@w3.org> 
			Subject: Re: Device description structures and families
			 
			 
			Yes, the ability to describe a stored family is an interesting 
			functionality. In the proposed solution there are families with a stored 
			definition (i.e. a company perform a study by which obtain a good 
			segmentation of devices and provides the resulting families as a 
			services) and temporary or dynamic families defined by a 'formula' or 
			'pseudo-code' by the requesting user, obviously, the query for the 
			family definition applies only to the first case. Technically, the 
			problem can be solved in the same way as the temporary or dynamic 
			families definition but in the opposite direction: the user can query 
			for the property definition and the DDR answers with the formula or 
			pseudo-code.
			 
			But, maybe there are some other cases in which the provider does not 
			want to provide that information, maybe the provider considers that this 
			information (the family definition) is his core business and do not want 
			to disclose it. We have to think on that scenario too.
			 
			In any case, we can add something like 'describeProperty' method at the 
			API level that can return the formula or the definition of a derived 
			property.
			 
			Related to the second point: if the family is a 
			previously-stored-definition one (i.e. provided by the DDR) there will 
			be no need for re-state the family definition. If the family is user 
			defined, the desired behavior  is to not need to re-state, but in that 
			case, DDRs have to maintain a session with the user allowing for an 
			initial definition an future many uses. We have to decide if the DDRs 
			must allow for a session type of communication or if DDRs must follow 
			the request/response schema.
			 
			If we are dealing with user defined (temporary) families the only two 
			ways that I can imaging is session maintenance or re-state the definition.
			 
			Well, those are just first thoughts about the problem, I hope it will 
			help to think on it and going further.
			 
			 
			 
			Raf.Casero
			 
			 
			-------- Mensaje Original --------
			  

				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 <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 <mailto:Kevin.Smith@vodafone.com> ] 
					Sent: 20 March 2007 15:48
					To: Rotan Hanrahan; public-ddwg@w3.org <mailto: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 
					 
					 
					 
					 
					 
					 
					[...]