- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 24 Mar 2004 13:50:31 +0200
- To: "ext Alberto Reggiori" <alberto@asemantics.com>
- Cc: Andy ext Seaborne <andy.seaborne@hp.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
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 Thursday, 25 March 2004 02:55:02 UTC