- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 24 Mar 2004 13:10:56 -0000
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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). > > 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. 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. 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. 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
Received on Thursday, 25 March 2004 01:39:12 UTC