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: Fri, 25 Sep 2009 00:20:19 -0400
Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-Id: <C60265FB-8A80-410C-B5FB-E35F31D49F7F@evilfunhouse.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
On Sep 25, 2009, at 12:09 AM, Lee Feigenbaum wrote:

> Ah, so you're suggesting this as a way for an endpoint to tell the  
> world what it does in the absence of FROM, FROM NAMED, and protocol  
> graph parameters? That makes perfect sense to me.
>
> (I had (mis-)interpreted it as a way to characterize the overall set  
> of graphs that the endpoint is capable of including in a query's RDF  
> dataset.)

Well, (thinking out loud here,) I'd imagine that the defaultGraph  
stuff would only be for systems that provide a default dataset. The  
sd:namedGraph properties, though, could provide descriptions of the  
graphs that are available for use in a requested dataset. Perhaps that  
suggests a slight name change with the properties -- maybe the  
sd:namedGraph property should actually be something like  
sd:availableGraph (while keeping the subsequent properties for  
graphName and graphDescription).

I imagine that URIs might pop up that can be used with the extension  
mechanism to describe the specifics of dataset handling (whether  
there's no dataset but lots of available graphs, or a default dataset,  
or no default but the ability to dereference any URL in a FROM/FROM  
NAMED clause). But in general I think there's value in providing  
enough in the SD vocab to point at descriptions of graphs (if any)  
that the endpoint is expected to commonly use (whether provided as a  
default dataset or not).

.greg
Received on Friday, 25 September 2009 04:20:56 GMT

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