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

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, and an algorithm uses the context to disambiguate which thing was
intended in that context.  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.

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.  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.
Thus the attempted solution is premature, much like attempting to design
an elephant enclosure after feeling only its tail.  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.  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.  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.  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.  


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 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.   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.  

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.
]]

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.  I have not yet seen anything in the need to
disambiguate a URI's referent, nor in the desire to establish
conventions for providing and locating URI definitions, that would
convince me that the RDF semantics should be changed.
 

Best wishes,


-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 9 October 2012 05:05:20 UTC