Re: Editor's Draft of ISSUE-57 URI Usage Primer

On Wed, Oct 10, 2012 at 12:24 PM, Alan Ruttenberg
<alanruttenberg@gmail.com> wrote:
> On Tue, Oct 9, 2012 at 3:15 AM, Noah Mendelsohn <nrm@arcanedomain.com> wrote:
>> I read the primer as providing useful advice for the many situations in
>> which, for good or bad reasons, such separate URIs are not created.
>
> It doesn't read like this. A good way to present that would be to make
> clear from the start that there are normative specifications about the
> use of URIs for making assertions (such as the assertion of a property
> value) and then give practical advise on how someone implementing
> incorrect behavior can adjust their system to be within conformance.

This is a good idea, but at present there *are* no such normative
specifications. Someone would have to write one, in order to be sure
that there was one. Is this what you had in mind? Maybe the 'URIs in
data' document could provide one or two; but its current message is to
ask others to go forth and write such normative specifications. It
would seem appropriate to provide the general format-independent
advice separately from format-specific advice; the TAG is willing to
take on the first, but not the second.

For RDF, one could write a specification that said, for example, that
it is correct to write
  <http://example/x> :recent-representation-contained-word "frog".
(or the same with a semantically indistinguishable URI) if and only if
some HTTP request of the form GET http://example/x yielded a 200
response where the content contained (after character decoding) the
string "frog". This isn't easy to test, since it requires knowledge of
the past, but at least it is objective.

I agree that something normative and concrete (objective, testable)
would be helpful. Without an operational semantics developers will
continue to be puzzled forever as to how to create conformant
artifacts. I would be interested in suggestions regarding how to do
this. Maybe something along the lines of
http://www.w3.org/2000/10/swap/doc/Reach, which is pretty concrete.
You can talk about "a graph serialized by a representation of the
entity identified by URI x" and assert (normatively) that this means
"a graph serialized by a representation retrieved [or retrievable,
choice here] using the URI u" without agreeing on what u identifies or
what "is a representation of" means.

I think the hope is that providing (normative) definitions of
"shorthand" and "immediate" (or whatever adjectives we end up
choosing) will be enough to help out specifications to come. This
would be similar to the way RFC 2119 defines "MUST" and so on for use
in other specs. I don't know whether this approach will work; we need
to probe this.

> It would present other proposals (such as the property punning) as
> non-conformant and therefore damaging to applications that depend on
> specifications. It would not propose new techniques that are at
> variance with normative specification. It might explain some of the
> consequences of specific non-conformant uses of URIs, such as when
> they are intended to be ambiguous by sometimes referring to one
> resource and sometimes to another.
>
> A primer doesn't show incorrect usage except to point it out as such.
>
> -Alan
>

Received on Wednesday, 10 October 2012 17:17:19 UTC