Re: DESCRIBE - description of a resource

On Nov 23, 2004, at 1:04 AM, Dan Connolly wrote:
>
> It's good to have a complete proposal.
>
> The material about DDDS and LSIDs doesn't seem to introduce
> any new aspects of the design. It might fit better in our
> Use Cases document.

I agree - SPARQL DESCRIBE provides a more general solution to the 
description of a resource problem

>
> If I understand correctly, what you're proposing is, formally,
> just:
>
> 	DESCRIBE returns any RDF graph.

yes that's the idea - the DESCRIBE operation allows to ask an 'open 
question' about a resource (or set of resources) to a SPARQL service 
without requiring the client to know the intrinsic data structure of 
the Data Graph being queried. The client might have partial knowledge 
about the target Data Graph being specified into the WHERE part of the 
query.

> I encourage you to be more concise; i.e. to use the fewest
> words that will make the design clear.

I will rework the text a little more trying to be more clear and concise

> I'm also interested
> to see test cases.
>
> The discussion of CBD and "bNode closure" suggests to me, again,
> that DESCRIBE should be a separate query language, and that so
> should CBD and the others. They should be given URI names
> for use in the protocol. There should be tests with black-and-white
> expected results, just like SPARQL SELECT. These languages
> can share syntax etc. with SPARQL, but they should be distinguished
> at the protocol level.

Yes this is a dangerous territory - I think is probably better the spec 
be completely agnostic to the algorithm being used to carry out a 
description o of a resource - and really let the server to decide what 
to return. So no explicit mention of CBD or other alternatives into 
SPARQL document itself. And eventually start working on a specific WG 
note about possible "description of a resource" algorithm alternatives.

I see at least three distinct possibilities to test DESCRIBE:

	1) we test it like ASK yes/no answer - simply expect a match/no-match 
answer ( num_statements > 0 )
	2) we provide some non-normative tests e.g. using "bNode clousre" 
algorithm  (which would put some requirements on the testing
	     machinery)
	3) we provide a two-steps testing by chaining two queries - one is the 
DESCRIBE which returns some arbitrary subgraph - and then apply
	  another SELECT query to it to check if some mandatory graph-pattern 
is matched on the subgraph of the DESCRIBE (a bit tricky though)

+1 on 1
+0 on 2
-1 on 3

>
> The way we've done this -- or started to do this, anyway --
> in our SWAP toolkit is to have
> properties that relate datastores, properties, and
> classes to services:
>
> In http://www.w3.org/DesignIssues/RDB-RDF.html we have

interesting, I will look into those...

To conclude, I will rework a little bit the text and remove explicit 
references to CBD or alternatives and repost to the list for last 
comments before asking the editors to include the text into the spec.

cheers

Alberto

>
> db:formService
>   relates a database to a service that groks a syntax
>   made from a particular HTML form I made up
> db:sqlService
>   relates a database to a service that takes SQL queries
> db:deltaService
>   relates a database to a service that accepts POSTed patches
>
> and in http://www.w3.org/2000/10/swap/doc/Reach we have
>
> log:definitiveDocument
>   relates a property to a document from which you can GET
>   a graph containing all true statements using that property
> log:definitiveService
>   relates a property to a service that takes queries (in N3,
>   I think) and returns definitive (i.e. complete by definition)
>   answers.
>
>
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>
-
Alberto Reggiori, Senior Partner, R&D @Semantics S.R.L.
alberto@asemantics.com  www.asemantics.com
Milan Office, milano@asemantics.com,   +39 0332 667092

Received on Thursday, 25 November 2004 11:54:03 UTC