W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Re: Service or graph store naming.

From: Gregory Williams <greg@evilfunhouse.com>
Date: Tue, 1 Mar 2011 00:25:23 -0500
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <A0C40123-8E51-4A54-94DB-F8F0029A1A6F@evilfunhouse.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
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.


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?

Received on Tuesday, 1 March 2011 05:25:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:03 UTC