- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Tue, 1 Mar 2011 10:02:23 -0500
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
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> ."
Why would that prevent the SD from containing other service descriptions?
thanks,
.greg
Received on Tuesday, 1 March 2011 15:02:58 UTC