W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Re: Service or graph store naming.

From: Gregory Williams <greg@evilfunhouse.com>
Date: Tue, 8 Feb 2011 17:28:36 -0500
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <93E4B99E-29DD-492E-8D17-31355DB56CFB@evilfunhouse.com>
To: Chimezie Ogbuji <chimezie@gmail.com>
On Feb 8, 2011, at 4:58 PM, Chimezie Ogbuji wrote:

> On Tue, Feb 8, 2011 at 9:06 AM, Andy Seaborne
> 
>> ?? It can't be functional in all cases - suppose the dataset description is
>> rather minimal.
> 
> I'm not sure what you mean.  I guess the question I was posing with
> that axiom is if it is the case that every service (SPARQL RDF
> protocol service or Dataset HTTP Protocol service) 'manages' one and
> only one graph store or RDF dataset.

To be clear, the part of the service description being discussed here is only the *default* dataset. A service can work over any number of datasets -- this is just the one that you get if you don't explicitly specify one.


>> And the domain of sd:defaultDatasetDescription is sd:Service and we might
>> have several services.
> 
> Ok, but can any of them be associated with more than one dataset or graph store?

Probably not -- it can be associated with a GraphCollection (in SD speak), though. The dataset is just a view onto some subset of the graph collection.


>> Can we have multiple service descriptions (query, update,
>> RESTDatasetService) in one description? If so, which URL gets that
>> description?
> 
> I wouldn't think so.  I've assumed that each service description
> document has only one sd:Service instance and

I think multiple service descriptions in one SD document would be perfectly fine. For example, having two endpoint urls /query and /update that use the same underlying service (with one accepting queries, the other updates), and both return the same document with two service descriptions (but perhaps a shared dataset description).

> (incorporating what
> Gregg said about the way the sd:url property is used), the service URL
> is
> 
> SELECT ?SERVICE
> {
>  { ?SERVICE a sd:Service FILTER(isUri(?URL)) } UNION { ?ALIAS sd:url ?SERVICE }
> }

This is a misunderstanding. In my last email I tried to make clear that what's in the document right now was a regression from what was intended. The intention was only { [] sd:url ?SERVICE }, but I'm starting to think the original motivation for that isn't actually that great, and we might want to change it to just { ?SERVICE a sd:Service } (and maybe drop sd:url). I think having both would be confusing and not provide that much benefit. Thoughts on this?

.greg
Received on Tuesday, 8 February 2011 22:29:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:45 GMT