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: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 24 Mar 2004 12:45:44 +0200
Message-Id: <670C3DB6-7D80-11D8-858C-000A95EAFCEA@nokia.com>
Cc: ext Alberto Reggiori <alberto@asemantics.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: "ext Seaborne, Andy" <andy.seaborne@hp.com>

On Mar 24, 2004, at 11:58, ext Seaborne, Andy wrote:

> (Patrick is odd levels, Alberto even levels.)
> -------- Original Message --------
>> From: Patrick Stickler <>
>> Date: 23 March 2004 18:31
>> On Mar 22, 2004, at 16:46, ext Alberto Reggiori wrote:
>>>>>> (b) a standard definition of a concise bounded description of a
>>>>>> resource (c) a standardized means to request the concise
>>>>>>      bounded description of a specific resource
>>>>> The matter of "concise bounded description"s should be an
>>>>> orthogonal issue to the general form of query and of protocol.
>>>>> That is, it would be good if it did not need to be distinguished
>>>>> in the rec.
>>> I would rather agree with Andy here instead
>>>> I don't agree.
> 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.

Well, the big difference between DAWG and DNS is that the volume of
those answers you haven't asked yet but might could be *alot* bigger
as a DAWG query response than a DNS response, and if my agent is
operating on a small device (e.g. a mobile phone) I don't want it
being force-fed *anything* that it has not asked for explicitly.

I.e., again, it's OK if some server provides for responses that are
more comprehensive than a concise bounded description -- but I want
it to be crystal clear what the default, presumed, expected nature
of a resource description is and for servers to provide *that*
form of description unless I say otherwise.

If some server is able to anticipate your possible future needs, fine,
and some agents may really benefit from that, but that is IMO a 
feature and out of scope.

> 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.

A concise bounded description, as specified by 
would do the same in the case of FOAF.

In fact, I've long considered adding a parameter to limit the number of
secondary levels in a resource description as in some cases, the bnode
closure can be overly large.

>>>> 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.

Right, and one can submit the exact same query to different 
models containing identity underlying graphs and get back different 
since what 'fetch' provides is implementation specific.

> I don't see why a standardized definition is needed in a W3C 
> recommendation.

So that there is consistency in the behavior of conforming servers.

So that when a client says "tell me about X" to a dozen different 
they understand exactly what is meant, and in the same way.

So that implementors creating new services which provide descriptions of
resources can be provided guidance about what an optimal level of 
for a description is.

I think there are many reasons why a standardized definition is needed
in a W3C recommendation.

And again, a standardized definition does not preclude other forms of
descriptions or any kind of value added functionality. It merely 
consistency across disparate implementations, which is, I believe, the
ultimate goal of the W3C.



Patrick Stickler
Nokia, Finland
Received on Wednesday, 24 March 2004 05:52:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:24 UTC