RE: About DESCRIBE

-------- Original Message --------
> From: Dan Connolly <>
> Date: 20 July 2004 18:19
> 
> On Tue, 2004-07-20 at 12:06, Seaborne, Andy wrote:
> > The DESCRIBE action is asking a "tell me about" question where the
> > client is not specifying the exact shape of the information to be
> > extracted but is asking an open question.  The results depend on
> > which RDF repository is asked.
> [...]
> > FetchQL (Joseki):
> > 
> > Joseki has a "query language" fetch that takes two forms to identify
> > the resource of interest: either the URI of the resource or an
> > identifying property/value pair.  What is returned is server
> > configuration dependent. Many people use bNode closure.
> 
> I like this sort of design where this feature as a completely separate
> query language.
> 
> RobS recently wrote:
> 
> [[
> With no definition of ordering, a "limit" feature violates
> many properties which can be desirable for a query language, including a
> simple desire for deterministic results.
> ]]
>  --
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0104.html
> 
> and I have a similar feeling about DESCRIBE. If the results aren't
> determined by the spec, it feels like a very different beast from
> SELECT/WHERE.
> 
> As chair, looking at WG mechanics, the test harness for DESCRIBE looks
> like it will be very different. EricP told me DESCRIBE gave him
> that "one of these things is not like the others" feeling when he
> was implementing it.

Yes, it is tricky and we should be cautious.  Some recommended (not
mandated) types of reasonable reply could be turned into test cases.  In
Joseki, the results are idempotent (you ask the question again, you get the
same result - sometimes called "stable") unlike the LIMIT case.  The server
shouldn't return different answers each time if tehre are no updates.  To
within bNode iosmorphism that is.  It is hard to see how a client can
navigate a graph without a unit of retrieval that includes items to be used
in the next step of traversal.

A fixed test is making assumptions about information returned.  The need for
this style of query action comes when client does not know, exactly what
information is available.  We could create testcases for the particular case
of bNode closure - it really is a very common case and only a few modelling
styls in the wild do not fit with it.  FOAF is one of the few examples but
there is nothing wrong about its data model.  Another case is "all
properties of" to level 1 or 2 away from a node but that does not capture
the motor cycle parts example very well.

It is interesting to note that DNS does include the ability to include
results to questions the client hasn't asked yet.  If you look up an MX
record, it is likely to give the A records for things touched to fill the
local cache.

Example: looking up a local SMTP server I get this reply : annotated and
chopped to remove redundat points (with "dig")

;; QUESTION SECTION:
;hplb.hpl.hp.com.               IN      MX

I asked "dig hplb.hpl.hp.com mx" - get the MX record for hplb.

;; ANSWER SECTION:
hplb.hpl.hp.com.        28800   IN      MX      10 gort.hpl.hp.com.
hplb.hpl.hp.com.        28800   IN      MX      10 colossus.hpl.hp.com.

The answer to this question.  2 servers.

;; AUTHORITY SECTION:
....

and in addition I get the A records for the items in the ANSWER SECTION
because the next thing my software is likely to say is "get me the IP
address of gort.hpl.hp.com" so I can open port 25 on it.

;; ADDITIONAL SECTION:
gort.hpl.hp.com.        28800   IN      A       15.144.59.32
gort.hpl.hp.com.        28800   IN      A       192.6.10.17
colossus.hpl.hp.com.    28800   IN      A       15.144.59.8
colossus.hpl.hp.com.    28800   IN      A       192.6.10.2

> 
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/

	Andy

Received on Tuesday, 20 July 2004 13:42:46 UTC