W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: service description vocabulary

From: Gregory Williams <greg@evilfunhouse.com>
Date: Mon, 28 Sep 2009 21:41:51 -0400
Message-Id: <BEE1C97C-721B-4AB9-82F5-15766A146CEB@evilfunhouse.com>
To: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On Sep 28, 2009, at 12:16 PM, Gregory Williams wrote:

>> Let's not fixate on Void. If Void is not sufficient then the  
>> community will come up with something more comprehensive.
>
> Well, I'm torn between saying "yes, absolutely," and thinking that  
> there are people (like the voiD folks) that are working on  
> describing RDF graphs, but that the SPARQL dataset case is specific  
> enough to SPARQL that maybe we should be providing the handful of  
> properties to allow leveraging graph description vocabularies in the  
> context of SPARQL datasets.

After talking a bit with Andy on irc earlier, and hearing some good  
suggestions, I'd like to know what people think of the following  
compromise. The service description spec will simple have a  
sd:datasetDescription property (and an equivalent property for  
pointing to a dereferenceable URL for the same data) that will point  
to some sort of description of the dataset (with the specifics being  
left to others to sort out). Subsequently, a WG or IG note can be  
published minting new properties if necessary (such as ex:defaultGraph  
and ex:namedGraph) and detailing how a vocabulary like voiD can be  
used to describe a SPARQL dataset.

This would keep the core service description vocabulary small, leaving  
the specifics of describing graphs and datasets to evolve in their own  
time, and focusing the vocabulary on just the important SPARQL- 
specific things. I expect some of the voiD supporters will follow up  
on this and push for more direct support to be included, but after  
hearing input from both sides and considering the available timeline  
and legitimate worries about trying to standardize this area too  
early, I think this is the best solution.

Thoughts?

thanks,
.greg
Received on Tuesday, 29 September 2009 01:42:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:08:28 GMT