Re: Service or graph store naming.

On 01/03/11 05:25, Gregory Williams wrote:
> On Feb 15, 2011, at 11:37 AM, Andy Seaborne wrote:
>
>> On 15/02/11 16:31, Gregory Williams wrote:
>>> On Feb 15, 2011, at 3:17 AM, Andy Seaborne wrote:
>>>
>>>>> • The RDF content returned from dereferencing a service
>>>>> URL<U> must include one triple matching: ?service sd:url<U>
>>>>> .
>>>>
>>>> I don't think that is necessary.  It is desirable for simple
>>>> processing of the RDF but MUST is far too strong.  After all
>>>> the service may have different names (over time, your name, my
>>>> name, bnode now, name later) - this is the semantic web and
>>>> there is not usually a unique name assumption.
>>>
>>> Understood. Would you be happy with a "SHOULD"? I'm OK with
>>> "bnode now, name later." What I'm worried about is "bnode now,
>>> name also now" -- I don't want to make it more difficult for
>>> clients trying to use service descriptions by requiring support
>>> for IFPs (or complex queries trying to work around the lack of
>>> support for IFPs).
>>
>> SHOULD is acceptable - personally, I'd make it more of a
>> style-of-RDF comment.
>
> Andy,
>
> 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.


Not that I'm intending to reuse the same machinery but experience with a 
similar framework, Jena assembler files, do this - there is no reason 
why multiple descriptions of things can't be in the same file.  It is 
easier and more convenient to, say, have one dataset description per 
file because the common use case is needing one dataset description, but 
in another less usual case (a Joseki server config file) it makes sense 
in that case to have several dataset descriptions in one file.

	Andy

Received on Tuesday, 1 March 2011 09:14:00 UTC