W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2004

Re: thoughts and some refs about AFS-2 UC (simplicity, minimalism )

From: Alberto Reggiori <alberto@asemantics.com>
Date: Wed, 24 Mar 2004 12:14:54 +0100
Message-Id: <7A46649D-7D84-11D8-ABC4-0003939CA324@asemantics.com>
Cc: Patrick Stickler <patrick.stickler@nokia.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: Andy ext Seaborne <andy.seaborne@hp.com>

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:18 GMT