Re: service description vocabulary

Hi,

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> ;
> 		sd:graphDescription <void-dataset-for-named-graph> ;
> 	] .
> ] .

So, in a quad store, you will describe each graph separately using  
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  
SD.
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).

So

<endpoint> sd:datasetDescription [
	sd:defaultGraph [
                 sd:graphName <graph-name> ;
		sd:graphDescription <void-dataset-for-default-graph> ;
         ] .
	sd:namedGraph [
		sd:graphName <graph-name> ;
		sd:graphDescription <void-dataset-for-named-graph> ;
	] .
] .

while I'd think a simple way would be

<endpoint> sd:datasetDescription <void-dataset-for-dataset> ;
	sd:defaultGraph <graph-name> ;
	sd:namedGraph <graph-name> .

Best,

Alex.

>
> 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
>
> [1] http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions
>
>

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Friday, 25 September 2009 07:39:09 UTC