Re: Service or graph store naming.

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?


Received on Tuesday, 1 March 2011 15:02:58 UTC