- From: Andrea Trasatti <andrea@trasatti.it>
- Date: Sun, 1 Apr 2007 16:37:43 +0200
- To: Rhys Lewis <rhys@volantis.com>
- Cc: <public-ddwg@w3.org>
- Message-Id: <21D9BD2D-B1BA-4A59-B1A2-EE3F886BBE2A@trasatti.it>
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 >> >> >> >> >> >> >> [...] >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >
Received on Sunday, 1 April 2007 14:37:54 UTC