- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 01 Mar 2011 15:33:48 +0000
- To: Gregory Williams <greg@evilfunhouse.com>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
On 01/03/11 15:02, Gregory Williams wrote: > On Mar 1, 2011, at 4:13 AM, Andy Seaborne wrote: > >> On 01/03/11 05:25, Gregory Williams wrote: >> >>> Having discussed the conformance issue some more with Lee and Sandro, >>> I think I'm more comfortable including some normative text. Rereading >>> this thread, I'm wondering why you think the MUST language is too >>> strong here. At one point I had text that said "MUST include one and >>> only one triple matching", but I don't think the text above ("MUST >>> include one triple matching") runs afoul of your concern about unique >>> names. What do you think? >>> >>> thanks, .greg >> >> It seems to me that mandating one discovery mechanism is a separate issue from service description. Highlighting and suggesting ways is good - we expect GET<service> to return a description. But there are other possible ways to discover service information, for example, a repository that is a collection of services descriptions all in one graph (this is RDF - merging information is OK). >> >> If I add a triple >> >> <newName> sd:URL<http://www.example/sparql/> . >> >> it is odd to me that a formally legal service description document >> becomes a non-document. Hence the "SHOULD" language suggesting helpful >> practice but recognizing it is not a necessity. >> >> Similarly, if I merge two separate service descriptions about two different, unconnected services, it seems reasonable to think of as still a service description of each. > > What I'm suggesting is that this case doesn't seem inconsistent with the suggested wording to me: > > "• The RDF content returned from dereferencing a service URL<U> MUST include one triple matching: ?service sd:url<U> ." "MUST include one" might imply "and only one" What about? "MUST include at least one" Andy > > Why would that prevent the SD from containing other service descriptions? > > thanks, > .greg >
Received on Tuesday, 1 March 2011 15:34:26 UTC