Re: Service or graph store naming.

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