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: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 24 Mar 2004 09:58:08 -0000
Message-ID: <E864E95CB35C1C46B72FEA0626A2E80801EA189A@0-mail-br1.hpl.hp.com>
To: Patrick Stickler <patrick.stickler@nokia.com>, ext Alberto Reggiori <alberto@asemantics.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>


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

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.

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


> > 
> > 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.
> 
> 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.
> 
> Patrick
Received on Wednesday, 24 March 2004 05:05:58 GMT

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