

Re: service description vocabulary

From: Alexandre Passant <alexandre.passant@deri.org>
Date: Fri, 25 Sep 2009 08:38:20 +0100
Message-Id: <B46F6BEC-02A5-455F-B8DC-6D8D399A9265@deri.org>
To: Gregory Williams <greg@evilfunhouse.com>

On 25 Sep 2009, at 03:41, Gregory Williams wrote:

> Beyond what's currently listed in the vocab section of the service  
> description page[1], I think we need a way to describe the dataset  
> provided by the endpoint. This goes beyond what things like voiD  
> provide which is a way to describe a single graph. Therefore, I'd  
> like to suggest something like this:
> <endpoint> sd:datasetDescription [
> 	sd:defaultGraph <void-dataset-for-default-graph> ;
> 	sd:namedGraph [
> 		sd:graphName <graph-name> ;
> 	] .
> ] .

voiD ?
Won't it be too much information in the SD, e.g. if I have 1 million  
RDF files in my store, will have 1 million of voiD descriptions in the  
It may be more useful to directly querying each graph to get that void- 
like information, if needed.

What about having a simple description listing the list of graphs +  
default one + the voiD description of the complete endpoint.

> The lack of naming symmetry between sd:defaultGraph (for default  
> graphs) and sd:graphDescription (for named graphs) could probably be  
> made better (maybe sd:defaultGraphDescription?), but this modeling  
> allows each graph in the dataset to be described as well as things  
> to be said about the entire dataset.

Strictly speaking, isn't the default graph also a named graph (since  
it generally also have its own URI).


<endpoint> sd:datasetDescription [
	sd:defaultGraph [
                 sd:graphName <graph-name> ;
         ] .
	sd:namedGraph [
		sd:graphName <graph-name> ;
	] .
] .

while I'd think a simple way would be

	sd:defaultGraph <graph-name> ;
	sd:namedGraph <graph-name> .



> Additionally, I was hoping to get feedback on whether people think  
> the vocab should distinguish between language extensions and  
> supported features? Is this a meaningful distinction? For example,  
> an extension that modifies the SPARQL syntax (e.g. to support the  
> BINDINGS keyword) versus a feature describing the algorithm used to  
> generate DESCRIBE results. The former clearly extends SPARQL, but  
> the latter works within the existing constraints of SPARQL. Thoughts?
> thanks,
> .greg

Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
Received on Friday, 25 September 2009 07:39:09 GMT
