- From: Alberto Reggiori <alberto@asemantics.com>
- Date: Thu, 25 Mar 2004 15:35:31 +0100
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mar 24, 2004, at 12:50 PM, Patrick Stickler wrote: >> >> 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. I have been trying to make a simple point - CBDs are useful and good construct to use - but too restrictive for the general case, which I think is what the DAWG should try to recommend instead e.g. "give me 'stuff' about X" where "stuff" is "application-profile" dependent. And X might be a URI as well as an arbitrary "RDF object" reference (e.g. typed bNode triple-pattern) Now - if we decide to put your CBD (or Andy's bNodes closure or whatever) definition into the spec it should only be for the savvy of "best practice" - but we should be clear to the user/reader that different federations might use/agree on different "description" definitions as requested by their applications. It is clear, that different "extraction algorithms" will be used/invented by users anyway. > > 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? Patrick - I feel we agree on the basic line - but what I would *not* like to see in the spec is one single black-on-white definition of "description about X" - we should stay as "opaque" as possible on that IMO > > 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...) I feel this (and other aspects arose in other use-cases threads) need further discussion some time - better now to concentrate to get some basic core spec out - but at same time is good to brainstorm on other issues and "keep an eye on them" cheers Alberto >> >> 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 Thursday, 25 March 2004 09:36:17 UTC