- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 26 Mar 2004 10:43:50 +0200
- To: "ext Alberto Reggiori" <alberto@asemantics.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mar 25, 2004, at 16:35, ext Alberto Reggiori wrote: > > > 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, Here's where I think we chiefly disagree. I consider CBDs to be crucial for the most typical, general use cases. Can you perhaps define for us (or just me) what you consider that general case to be and explicitly why CBDs don't work for that 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. I think what is application dependent is how the client uses the returned description, not the form of the description itself. I'd rather have the DAWG servers be fairly generic and agnostic about application logic, letting clients decide how to consume the information they recieve, rather than tailoring responses to precisely what a particular client needs. > And X might be a URI as well as an arbitrary "RDF object" reference > (e.g. typed bNode triple-pattern) Your use of the term URI sometimes confuses me. A URI is a string which names/denotes a resource. If you want to talk about that URI, you have to reify it in some manner (I've long ago proposed a special URI scheme 'uri:' for reifying URIs). If the URI denotes an RDF object, then a description of that object would not be the RDF object itself, but *another* RDF object that corresponds to the description of the first. > > 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. This is what I've been proposing all along. Please re-read my earlier postings and I think you'll find that I suggest this over and over... The bottom line, is that unless the client/server agree otherwise, the default should be used. >> >> 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 > Not one single this-is-all-you-can-use definition, but definitely a clear unambiguous this-is-what-you-should-use-if-not-specified-otherwise definition. I.e. I'm talking about a SHOULD not a MUST. >> >> 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" Well, since I consider this central to any core spec, I think we need to work through this... Patrick > > 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 > > -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Friday, 26 March 2004 03:45:07 UTC