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

On Tue, Oct 9, 2012 at 1:04 AM, David Booth <david@dbooth.org> wrote:
> Substantive comments on:
>> http://www.w3.org/2001/tag/doc/uri-usage-primer-2012-10-03/
>
> 1.  Punning = Ambiguity + Algorithm.
> This document represents a significant step forward, as it begins to
> recognize the inevitable ambiguity about the referent of a URI, and
> works within that ambiguity by suggesting that it be treated as a form
> of punning.  "Punning" means that a name is used to denote more than one
> thing

"Punning" in the context of the semweb specifications, means the use
of a URI as more than one of  an individual, a class, a property, or
some other structure attached to it by a semantic extension. It is
intended that these "mean" the same thing, as stated at the beginning
of AWWW "By design a URI identifies one resource".

Punning, in this sense, is not something extra, but rather something
that is part of the specification of RDF. One of the reasons OWL 2
RDF-based semantics differs from the Direct semantics is because it
lacks an inference rule that ensures that if two URIs denote the same
individuals, then the property extensions and class extensions must be
the same as well. I.e. it *breaks* punning.

>, and an algorithm uses the context to disambiguate which thing was
> intended in that context.

Any such algorithm is outside of, and in contradiction to, the specs
as intended.


> In this case the context is determined by the
> RDF property that is used to make a statement about the referent of the
> URI.  The document proposes that different kinds of properties be
> defined, to distinguish between "landing pages" and the resources that
> they describe.

It does so in a way incompatible with the design of the relevant
specifications. In those specifications, statements about relata of a
property are inferred in specific ways, for example by the use of
class assertions (rdf:type) about the resource (of which landing page
is one sort) and domain and range assertions on the property.

> 2.  The examples are excellent for demonstrating the harm that
> ambiguity, between a web page and the resource it describes, can cause
> to applications that need to make distinctions along this axis of
> disambiguation, such as an application that is attempting to properly
> assign license terms.
>
> 3. Although this document has *begun* to recognize and address the issue
> of ambiguity, it only does so for one particular axis of disambiguation,
> which it singles out: the distinction between a landing page and its
> subject.

And, unfortunately, when it has done so, it has offered poor advise,
advise that is at variance with the specifications and with the goals
of the semantic web.

> There are two problems with doing this.  One is that the
> document does not yet recognize or embrace the full nature of the
> ambiguity problem that lies at the heart of the use of URIs as names.

It seems clear that you are confusing ambiguity and vagueness. It
seems to me that before you continue making further assertions about
ambiguity in this context, you should understand and integrate this
into your thinking.

> Thus the attempted solution is premature, much like attempting to design
> an elephant enclosure after feeling only its tail.

The solution, I'm afraid to say, is not premature. It is simply
unworkable without fundamental changes to the specifications of RDF,
OWL, and it is not even clear whether it can possibly work, and if so,
whether in "working" it wouldn't be just as much at variance with some
important segment of efforts currently using RDF.

>  The second issue is
> that, although there is nothing innately wrong with giving advice about
> how one might make distinctions along this particular axis of
> disambiguation, by focusing on this axis alone -- at the exclusion of
> all others -- there is an implication that this axis is somehow critical
> to Web architecture, which is misleading.  This axis is no more
> important to Web architecture than any other axis of disambiguation that
> some other application might require.

It's a pretty important one. The evidence is the amount of discussion
it has engendered and the number of cases where examination of current
usage, in comparison to published specifications, finds error. I don't
think it helps to minimize the importance of the issue, or to blur it
by putting in the big bag you consider appropriate recognition of
ambiguity.

> Web architecture *does* need to
> provide mechanisms to allow disambiguation along any desired axis, in
> order to support the needs of any desired application.  It does not need
> to single out any particular axis or application for special treatment.
>
>
> 4. This document both introduces a particular convention for the use of
> "punning" properties that are used to disambiguate between a landing
> page and its subject, and it attempts to give general advice on how URI
> definitions might be provided and located.

It does so in a way that is in contradiction with existing
specifications, and in a format that suggests authority and best
practices. That's a mistake. The advise regarding documentation of
those properties doesn't even follow good practice in that it
identifies the property by a string in some JSON rather than with a
URI.

> These are quite different
> topics.  Instead of bundling them together into one document, I think it
> would make more sense to treat them separately, for a couple of reasons.
> First, the punning technique that is suggested is new, and could use its
> own focus, discussion, and maturation.

I come to a different conclusion. A "primer" shouldn't introduce new
elements of architecture. It should be a document that is derivative
of a specification. There are specifications that exist that cover the
space that this new "technique" occupies. A proper place to introduce
it would be in a letter to appropriate working groups working on the
problem, not in a "primer".

> Second, as explained above, when
> giving general advice on providing and locating URI definitions, there
> is no need to single out this one axis of disambiguation from among the
> infinitely many ways that an application may need to disambiguate, and
> doing so may be misleading.

How many times are you going to say this, denying what Jeni, many of
the TAG, and many other workers in the semantic web effort have
concluded?

>
> 5. I am not convinced that this technique of punning and the use of
> imaginary, parallel properties will ultimately be more attractive, to
> RDF authors who wish to disambiguate on this axis, than simply minting a
> different URI for the landing page than its subject.

It's comforting that we agree on this point, at least.

> It seems like a rather large amount of mental contortion for a small gain.  If people
> are told to use this convention, will they be any more apt to comply
> than if they are told to mint separate URIs?  I personally think that
> the advice to mint separate URIs is easier to digest and swallow, but
> this may be a matter of personal taste.

It's also the specified behavior.

> I think we should try to get more input on the palatability of this approach before trying to promote
> it too much.

>
> 6. In section 5.4
> http://www.w3.org/2001/tag/doc/uri-usage-primer-2012-10-03/#locating-property-documentation
> I notice that the idea of providing resolvable URIs for properties and
> classes in RDF is given scant attention: it is only mentioned at the
> very end of the list of mechanisms.  I think this is a mistake.
> Following principles of Linked Data, the self-describing Web, and
> self-describing data in general, I think this section should give *top*
> prominence and highest recommendation to the use of resolvable URIs for
> properties and classes in RDF -- not external metadata or mechanisms
> that can become disassociated from the data.

That's 2!

>
> 7. In section 6.1.1 I am puzzled at this advice:
> [[
> Metaformats such as RDF that incorporate URIs as part of their core
> information model should document the default interpretation of those
> URIs: whether properties for which no other information is available
> should be interpreted as applying to the content available at those URIs
> or the things those pages describe.
> ]]

They are documented to refer to only one thing.

> Is this suggesting that the RDF semantics be re-written to incorporate
> some kind of default interpretations?  I do not understand what is being
> suggested here, but I would be wary of any TAG advice that suggests
> changing the RDF semantics.

3!

-Alan

Received on Wednesday, 10 October 2012 16:18:18 UTC