- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 24 Mar 2004 16:00:50 +0200
- To: "ext Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mar 24, 2004, at 15:10, ext Seaborne, Andy wrote: > Patrick: >> Andy, Alberto, are you opposed to the definition of a default/typical >> form of description which allows for any number of additional forms of >> descriptions to be provided by any given server? > > I wish to see the working group agree the *need* for it to be in the > rec. > (normative or non-normative). Absolutely. I've presented several use cases which reflect this need, and it's up to the WG to decide if those use cases merit being addressed. > >> >> Or is your objection absolute, against any kind of definition >> whatsoever? >> (in which case, I'd ask why you would be opposed to facilitating >> consistency >> across disparate implementations...) > > And to be clear, I am making no absolue objection to anything. It is > far > too early to even think of such things. I want an early rec, > delivering > some significant value now, not a later rec. covering a wider range of > values. I believe that the early/simple rec. will trigger community > requirements we will not think of in this cycle, or not weight highly > enough. Quite. And I feel that the ability to obtain a concise bounded description of a resource to be a significant short-term need, and that wanting descriptions of resources rather than variable bindings to be a primary form of query result. > > Earlier in the message you said: > >> one, basic, default, most >> generally useful/optimal form/resolution of description > > and as the discussion shows the FOAF case makes that hard. Eh? I don't see the discussion showing anything of the sort. Addressing FOAF isn't hard at all. In fact, the problem is addressed quite simply, with a single parameter. I honestly feel that you and Alberto are painting dragons that don't exist. If there truly are signficiant problems/issues, fine, let's discuss them. I'm not blindly obsessive about this, even if I do feel strongly that it is needed. But please present concrete examples of such problems/issues. I think it's fair that if anyone is going to dismiss a use case or issue as out of scope, that they defend their dismissal with concrete evidence/argument. I've tried to do so myself, even if perhaps imperfectly at times. You and Alberto seem to be arguing for dismissal of over half of the use cases I've submitted. I think it's fair to expect you to back that up with very convincing arguments. > There also seems > a tension between "optimal" and "basic". The "content negotiation" > approach > seems over doing it but interesting. It would not need a default. No more so than GET needs to ever return anything if conneg is not used, eh? ;-) If there's no default, then there's no point. Because then there's no basic interoperability. Patrick > > > Andy > > -------- Original Message -------- >> From: Patrick Stickler <mailto:patrick.stickler@nokia.com> >> Date: 24 March 2004 11:51 >> >> On Mar 24, 2004, at 13:14, ext Alberto Reggiori wrote: >> >>> >>> as far as I understand (and implemented [1]) the "fetch object" >>> method >>> for a Concise Bounded Description (CBD) [2], Patrick's algorithm >>> starts from a URI denoting some resource, visiting nodes down the >>> graph till it finds another URI (leaf node) - and then return all >>> visited statements to the client. Quite neat and common case and >>> works >>> pretty well for I2C DDDS or MGET methods - but at same time we found >>> the algorithm not general enough. >>> >>> A server might as well decide to go further than leaf URI nodes for a >>> certain number N of levels in the graph, or using some server side >>> specific rule, perhaps following specific typed nodes - and so on. >>> >> >> I'm not at all proposing that we close the door on other >> forms/resolutions >> of descriptions -- only that we define at least one, basic, default, >> most >> generally useful/optimal form/resolution of description so that, >> unless >> otherwise specified/requested/indicated, that's what should be >> used/returned. >> >> It's like content negotiation. With conneg, you can specialized your >> GET >> request -- but it's optional, and not all servers support it. >> >> So, while some knowledge sources may support the request of special >> kinds >> of descriptions, they should also support the default, and support for >> other than the default type of description would be optional for DAWG >> conformance. >> >>> in other words, CBD as defined by Patrick today is about returning >>> "outbound" nodes from a URI (Andy's bNodes closure is another example >>> of that AFAIK) - while sometimes the server might need/want to return >>> "inbound" nodes or a mixture of the two. >>> >>> I found the RDF Objects [3] paper explaining this point a little bit >>> more clearly. >> >> I'll have to have a look at that... >> >>>> >>>> >>>> I don't see why a standardized definition is needed in a W3C >>>> recommendation. >>> >>> indeed! >> >> Again, it seems to me that I am being misunderstood as proposing >> a prescriptive/restrictive definition rather than a default/typical >> definition. >> >> Andy, Alberto, are you opposed to the definition of a default/typical >> form of description which allows for any number of additional forms of >> descriptions to be provided by any given server? >> >> Or is your objection absolute, against any kind of definition >> whatsoever? >> (in which case, I'd ask why you would be opposed to facilitating >> consistency >> across disparate implementations...) >> >>> >>> we will perhaps need one special keyword/clause into our DAWG query >>> language for the specific case of CBD or fetch_object() (using bNodes >>> closure) >> >> I have been thinking along the lines of a single parameter 'uri=' >> which, if specified, constrains the input query to the concise bounded >> description of the resource denoted by that URI. >> >> If no query is otherwise specified, then the request is for the entire >> description. If a query is specified, then the description is returned >> only if the query matches the description (e.g. give me the >> description >> if the ex:status property is equal to ex:active, otherwise, don't >> return anything). >> >> And, BTW, bnode closure is IMO insufficient. Reifications should be >> included. It should also probably be possible to limit the number >> of levels of bnode closure, in case one is querying knowledge based >> on FOAF like models... maybe even facilitating arbitrary levels >> in general, e.g. >> >> uri= the URI of the 'target' resource >> >> max-levels= maximum number of bnode closure levels >> (default = infinity) >> >> levels= number of description levels below 'target' >> resource to include (default = 0) >> >> If max-levels < levels than treat max-levels as equal to levels. >> >> etc... >> >> Patrick > > -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Wednesday, 24 March 2004 09:24:29 UTC