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

On Wed, Mar 24, 2004 at 12:45:44PM +0200, Patrick Stickler wrote:
> 
> 
> 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 
> value-added
> 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 
> http://sw.nokia.com/uriqa/URIQA.html#cbd,
> 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.

If I do my arithmetic right, that would be necessary when querying a
foaf entity. Given a typical foaf graph:

  _:1 foaf:firstName "bob"
  _:1 foaf:surname "smith"
  _:1 foaf:knows _:2
  _:2 foaf:firstName "bob"
  _:2 foaf:surname "smith"
  _:2 foaf:knows _:3 ...
  _:1 foaf:knows _:4
  ...

the data bounded by a CBD would encompass most of the graph.

> >
> >>>
> >>>>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 
> Joseki-accessible
> models containing identity underlying graphs and get back different 
> responses,
> 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 
> servers,
> 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 
> resolution
> for a description is.

Suppose we had a query language that allowed some sort of URI-labeld
profiles.
  GET http://liber.examaple.com/book1
  Profile: http://www.example.com/profiles/Book

This would allow for the definition of different queries, some of
which would specify that no addtional data would be returned, and
would thusly be more attractive to small devices at the end of long
thin pipes (network term meaning slow data feeds).

If the DAWG query language did not specify that returned triples
and/or bindings must all be specified in the query, folks wishing
to define such profiles could define them in terms of properties.
Query servers that didn't understand these profiles would simply
give no results for a query like:

  <http://liber.examaple.com/book1> <http://www.example.com/profiles/Book> ?x

The upside is that you get distributed and domain-specific profile
definition. The downside is that a client can't lean on a
specification that says "if you answer this port, or claim to handle
this SOAP message, you must also understand this profile."

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

I suspect that defining the perfect resource description query is as
difficult as defining the perfect ontology. The parallel follows for
"good enough" queries and ontologies. W3C doesn't define (very many)
ontologies, but is rather keen on specifying ontology definition
languages. Hence my compromise suggestion above.

> And again, a standardized definition does not preclude other forms of
> descriptions or any kind of value added functionality. It merely 
> facilitates
> consistency across disparate implementations, which is, I believe, the
> ultimate goal of the W3C.
> 
> Patrick
> 
> --
> 
> Patrick Stickler
> Nokia, Finland
> patrick.stickler@nokia.com

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Wednesday, 24 March 2004 07:38:53 UTC