Re: Device description structures and families

I guess that this is my own misinterpretation of the RDF Primer [1].  
In Chapter 2.1 it says: "it is also important to be able to record  
information about many things that, unlike Web pages, do not have  
network locations or URLs.". Later says:"URIs are not limited to  
identifying things that have network locations, or use other computer  
access mechanisms. In fact, a URI can be created to refer to anything  
that needs to be referred to in a statement, including
network-accessible things, such as an electronic document, an image,  
a service (e.g., "today's weather report for Los Angeles"), or a  
group of other resources.
things that are not network-accessible, such as human beings,  
corporations, and bound books in a library.
abstract concepts that do not physically exist, such as the concept  
of a "creator".
"

I have not found anything, at least in the Primer, that says that the  
owner of the URI is responsible. In theory, what stops me (Andrea  
Trasatti) from using a URI such as http://www.w3.org/some/path/ 
file.html#Andrea in my RDF (even if I'm not the owner of w3.org)?

This is certainly turning into a discussion about RDF and not  
structures in the DDR. I think it's better to move this discussion in  
private... Or I'll just ask my questions to the RDF people.

- Andrea

[1] http://www.w3.org/TR/rdf-primer/


Il giorno 26/mar/07, alle ore 16:36, Rhys Lewis ha scritto:

> Hello everyone,
>
> The mechanism for assuring uniqueness of HTTP URI's is a  
> combination of their structure and of the reliance of the Web on  
> the internet's Domain Name Service. URI owners have to have rights  
> to the part of the domain in which they can create URIs. They also  
> have a responisbility not to create URI collisions. [1] discusses  
> this. Of course, implementations that help people to achieve those  
> recommendations are a different matter.
>
> In this particular case, URIs related to W3C specifications are  
> normally within the W3C's domain and are allocated by the  
> organisation. That would presumably work for families that were  
> standardised. For extensions, then presumably the company or  
> organisation making the extension would use a URI in a domain that  
> they owned.
>
> Maybe I'm missing something here?
>
> By the way, pointing this out doesn't necessarily mean that I'm  
> necessarily in favour of representing families explicitly in the  
> DDR. I haven't really formed a view. I just thought it worth  
> responding to Andrea's point about URIs and collisions.
>
> Best wishes
> Rhys
>
> [1] http://www.w3.org/TR/webarch/
>
> From: public-ddwg-request@w3.org [mailto:public-ddwg- 
> request@w3.org] On Behalf Of Andrea Trasatti
> Sent: 26 March 2007 14:53
> To: public-ddwg@w3.org
> Subject: Re: Device description structures and families
>
> This feels a lot like RDF's idea that if something points to a URI  
> it must be unique.
> Something that actually strikes me about RDF is that the URI is not  
> required to actually exist, so how could you guarantee that nobody  
> else is using the same non-existing URI?
>
> Also, wouldn't it generate a run for the best names as it happens  
> with domain names? Would you suggest to lock premium names as  
> someone recently did?
>
> - Andrea
>
>
>
> Il giorno 26/mar/07, alle ore 14:27, Rotan Hanrahan ha scritto:
>
>> Here’s an idea…
>>
>>
>> The uniqueness of family definitions can be guaranteed if we use  
>> URIs to indicate families. If we dereference a URI we should  
>> obtain an expression that is applied to values in the known  
>> vocabulary (-ies). Short names like IsPDA can be defined centrally  
>> for convenience, but this would only be a shorthand for the  
>> corresponding URIs, and only for a few key definitions.
>>
>>
>> A DDR could, if it wished, restrict the use of Family URIs to a  
>> defined set of sites, thus taking some control of arbitrary query  
>> expressions.
>>
>>
>> We might  also insist that the information obtained at a Family  
>> URI was fixed, so that the expressions could be cached, or  
>> alternatively use the existing HTTP caching mechanism with  
>> extended periods of validity (because the Family definitions  
>> should change very seldom, if ever).
>>
>>
>> This is just an idea. I am not saying that this is the way to  
>> implement the DDR, as we should avoid getting into the  
>> implementation details. It is just useful to consider the  
>> implementation possibilities so that we are confident that our API/ 
>> vocabulary ideas are viable.
>>
>>
>> ---Rotan.
>>
>>
>> From: public-ddwg-request@w3.org [mailto:public-ddwg- 
>> request@w3.org] On Behalf Of Andrea Trasatti
>> Sent: 26 March 2007 13:12
>> To: public-ddwg@w3.org
>> Subject: Re: Device description structures and families
>>
>>
>> Kevin, the use of the term "view" was to give an idea of what I  
>> meant.
>>
>>
>> An idea (and I'm not saying this is necessarily the way to go, but  
>> just sharing some thoughts) would be to have an admin interface  
>> where an administrator can define a family say "PDA are all those  
>> devices with at least 320px wide screen, stylus OR full keyboard,   
>> PC sync". It's the definition of the admin of MY DDR. The API  
>> should also provide a way for this DDR to communicate to other  
>> DDR's or clients what the family definition is.
>>
>> Other DDR's may create a family called "PDA" as much as mine, but  
>> with different filters. If the group thinks the family names  
>> should be unique, then we need a central authority to assign  
>> names, but this is far out of scope, IMHO.
>>
>>
>> How the DDR will implement the definition and "maintenance" of the  
>> family is up to the DDR developer. It can be a view, it can be a  
>> stored procedure, it can be a csv file generated once a day. It  
>> will be up to the DDR owner to let its customers know if the list  
>> of devices that are part of a family are outdated or MIGHT be  
>> outdated or are generated in real-time.
>>
>>
>> - Andrea
>>
>>
>> Il giorno 26/mar/07, alle ore 12:25, Rotan Hanrahan ha scritto:
>>
>>
>>
>>
>> As I see it, José was talking about a particular type of  
>> structure: a family of devices. Such a family is defined by a  
>> membership expression. The question is: who provides those  
>> expressions? It is possible that these are provided centrally, so  
>> that there is, for example, a central definition for the  
>> IsSmartPhone family and the IsPDA family etc. In this case, the  
>> expressions can be pre-evaluated and the results stored. No  
>> performance issues to worry about.
>>
>>
>> But perhaps, as a user, my idea of a PDA is not the same as the  
>> official definition, so perhaps I want to use a different  
>> expression. This would be a run-time expression. Do we want to  
>> support such a use case? If so, it opens all kinds of performance  
>> and security issues.
>>
>>
>> Of course, you could always mirror a DDR internally, and then run  
>> your dynamic queries against your own mirror. That way, any  
>> performance impact will be absorbed by the user of the DDR, not  
>> the provider.
>>
>>
>> This approach might have implications further down the line.  
>> Suppose the DDR expands, as it will be designed, to include  
>> streaming capability information. In such a case, a local mirror  
>> of the DDR for a video streaming service will only be interested  
>> in data pertaining to streaming. How would this mirror indicate to  
>> the DDR master that it only wants a particular subset of data to  
>> be mirrored? This is another use of the “family” idea, but not  
>> just applied to devices – it is applied to subsets/categories of  
>> data within families of devices.
>>
>>
>> In terms of what the DDWG *needs* to do, if we have a way to  
>> identify a single device (using an appropriate interpretation of  
>> “device”) then I should be able to query the DDR for one/some/all  
>> of the data relating to that device that is held in the DDR. How  
>> the DDR resolves that query to produce the result is an  
>> implementation issue. In theory you could implement it with a  
>> linear search through a flat file. The DDWG is not responsible for  
>> determining how the processes are implemented, though it makes  
>> sense for us to keep an eye on possible implementation issues,  
>> hence my concern for performance and security.
>>
>>
>> ---Rotan.
>>
>>
>> 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] On Behalf Of Rafael Casero
>> Sent: 23 March 2007 14:06
>> To: Andrea Trasatti
>> Cc: 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
>>
>> 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]
>> Sent: 20 March 2007 15:48
>> To: Rotan Hanrahan; 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
>>
>>
>>
>>
>>
>>
>> [...]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>