Re: RDF dataset/SPARQL endpoint descriptions

On Sep 8, 2009, at 2:21 PM, Andreas Langegger wrote:

> As I suggested before I would separate service and dataset  
> descriptions (e.g. provide DESCRIBE DATASET and DESCRIBE SERVICE and  
> sub queries such as SELECT * FROM { DESCRIBE DATASET } WHERE ...  
> later on)

It looks like a "DESCRIBE DATASET/SERVICE" won't be the path taken, as  
there are some concerns about this operating at the query engine  
level, when it's really a protocol operation. The exact method for how  
to do it hasn't been nailed down yet, but some of the options under  
discussion are:

- an HTTP response header linking to a service description document
- the use of the HTTP OPTIONS verb on the endpoint URI
- using content negotiation on the endpoint URI to request RDF (or  
possibly having the endpoint URI return RDFa)
- a new protocol operation (/sparql?serviceDescription)

> In order to benefit from HTTP caching, the endpoint should not only  
> provide dataset descriptions (possibly including statistics) as  
> SPARQL results, it should allow to retrieve them via HTTP and check  
> the Last-modified header, etc. That's what I'm doing when monitoring  
> datasources for SemWIQ => exec DESCRIBE SERVICE and follow the  
> void:Dataset link.

Can you explain why returning a dataset description as SPARQL results  
would be better than returning it as RDF?

> For query federation, it would be very useful if the future SPARQL  
> REC supports BINDINGS such as introduced by Eric [2] before. My  
> proposal works with a set of bindings with a special "null" keyword  
> for unbound variables, e.g.:
...
> It is not much effort for implementers and a federated query  
> processor can then process pipelined blocks of queries more  
> efficiently.

Unfortunately, this won't be part of the next SPARQL version, but  
service descriptions should allow any implementations to declare that  
they support such an extension.

.greg

Received on Friday, 11 September 2009 02:16:56 UTC