- From: Alberto Reggiori <alberto@asemantics.com>
- Date: Wed, 24 Mar 2004 12:14:54 +0100
- To: Andy ext Seaborne <andy.seaborne@hp.com>
- Cc: Patrick Stickler <patrick.stickler@nokia.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mar 24, 2004, at 10:58 AM, Seaborne, Andy wrote: > > Patrick: >>>> Unless you are intending to restrict query responses solely to >>>> bindings (which I think is both unnecessary and fails to meet >>>> the needs of a very broad range of use cases that we've already >>>> identified) you need to define what a "description" is. > Alberto: >>> >>> I do not think so - I rather would find such a requirement quite >>> restrictive > > Patrick: >> >> ??? >> >> How so? Can you give some clear use cases where having a precise >> definition of a resource description prevents some key functionality? >> > > Example: a query gets information about a book. The server also sends > details about the author as well. c.f. DNS sending answers to lookups > you > haven't asked yet but are likely to. yes - in the general case the server/service might decide to return more or less triples as needed 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. 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. > > A FOAF example, which is good as a FOAF graph is all bnodes, would be > to > return the description of the person specificied by foaf:mbox and the > defining properties of the foaf:knowns foaf:Persons so that further > graph > retrievals can be done. actually FOAF is a tricky example - due that most file do not use explicit URIs to pin-point to people (while they probably should? [4] ) but rather they use the so called "reference-by-description" [5] Andy's original example of getting information about a book having a specific URI is probably clearer for Patrick. even though your FOAF example above is as well interesting.... would the "tell me about that URI..." use case rather become "tell me about that 'thing'" ? where 'thing' might be a URI or a kind of triple-pattern which would identify a specific bNode you can not name/refer-to E.g. "get all FOAF for 'Mr. Jones' from a server" the CBD alg would not work because URIs are not generally used for foaf:Agent/foaf:Person - even so, it would stop on "leaf" properties such as foaf:interest - what is needed is a more general approach/method to ask "questions" about a certain 'thing' >>>> I don't think it should be left up to each implementor to define >>>> themselves what they will consider a description (such as is the >>>> case with Joseki's 'fetch' operation) >>>> but that there should be >>>> consistency across implementations insofar as the default, normal >>>> behavior of DAWG conformant tools. Implementations may choose to >>>> offer other flavors of descriptions, fine, but we really do need >>>> to have a precise, standardized definition of a "concise bounded >>>> resource description". > > A Joseki 'fetch' isn't just about "descriptions" of things. Its about > gets > parts of grpagh - your "desriptions" are one case of that. > > I don't see why a standardized definition is needed in a W3C > recommendation. indeed! >>> even though that would be too much "application specific" - while we >>> should try to be completely "opaque" on the "about" definition IMO >> >> >> So one implementor has a minimal definition, which excludes any >> statements with bnode subjects as well as all reification statements >> (providing too little information in the response even though that >> knowledge is there in the knowledge store) and another implementor >> has a maximal definition which includes up to 5 levels deep >> descriptions >> of other URI denoted resources "just in case" such information is >> needed >> (providing far too much information, including knowledge which is not >> directly relevant to the resource in question)... No thanks. of course - two clients or servers in the "same" federation might agree on what a "description" is - but this would be just specific to that domain/application >> >> I'm not proposing that an implementation is limited to returning >> descriptions according to a standard definition, but that >> having that standard definition as the default, unless otherwise >> specified, allows clients to know what they will be getting >> and that it will be the minimal, relevant body of information >> about a resource. 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 hope I managed to be clearer this time :) cheers Alberto [1] http://demo.asemantics.com/rdfstore/fetchobject/ [2] http://sw.nokia.com/uriqa/URIQA.html#cbd [3] http://www.hpl.hp.com/techreports/2002/HPL-2002-315.pdf [4] http://lists.w3.org/Archives/Public/www-rdf-interest/2004Mar/0000.html [5] http://rdfweb.org/mt/foaflog/archives/2003/07/10/12.05.33/
Received on Wednesday, 24 March 2004 06:16:12 UTC