Re: Proposal to amend the httpRange-14 resolution

On Tue, 2012-03-27 at 21:02 -0400, Jonathan A Rees wrote:
[ . . . ]

> The point here is that it's all about meaning, not truth.

+1 that it's not about truth.

-1 that it's about meaning.  

It is not.  That is a huge, pervasive misconception that we need
to get past.  It is all about *definitions* and *usefulness*.
Whether/how those definitions are interpreted as meaning or
truth is completely irrelevant to the architecture.

As a vague overarching goal, it is fine to say that we're after
meaning, and even truth!  But as soon as we set out to have
serious engineering discussions on semantic web architecture,
such language is harmfully misleading:

 - The mere term "the meaning" wrongly suggests that there *is*
(or can be) a single meaning for a URI i.e., that it is possible
to have an architecture in which each URI has a unique referent.
That *is* possible within a particular client application
-- or in RDF semantics parlance, a particular semantic
"interpretation".  But it is impossible at the global level
that the architectural must deal with.

 - It leads to rat holes such as whether something really is
or is not an "information resource", or (even if that term is
avoided altogether) exactly what properties should be assumed
if something has a "representation".

 - It confuses the engineering problem and leads to hopelessly 
convoluted definitions, like this one, from the "baseline"
document:
[[
  A representation is hereby defined to _carry_ URI documentation
  for a given URI if it contains the URI documentation (with
  or without other information), the syntax and semantics of
  the documentation is as determined by the media type of the
  representation, and the documentation occurs unqualified. It
  is difficult to define "unqualified" precisely for all media
  types, but we generally mean by this that the documentation is
  given "sincerely", not quoted, conditionally, or modally. That
  is, if D is URI documentation and a carrier says in effect
  that D is not or might not be true, then D, although it
  occurs in the carrier, is not considered to be carried by
  it. (E.g. documentation that occurs in an XML literal inside
  of an application/rdf+xml representation is not unqualified,
  and therefore not "carried" by it under the present definition.)
  
  A "URI documentation carrier" for a URI is a representation that
  carries URI documentation that bears on the meaning of that
  URI. Applying the adjective "nominal" is a technicality that
  signifies that being a URI documentation carrier for the URI
  is expected according to this specification, but that it might
  not actually be one (for example, the representation might be
  empty, or it might contain information, but not information that
  helps to document the URI, perhaps as the result of a mistake).
]]

I recognize the desire to have RDF statements on the web *mean*
something in the real world, and clients are free to interpret
them that way if they *choose* to do so.  Furthermore, it is
important that the architecture support clients' ability to
interpret them that way *if* they choose.  That is critical.

But from an architectural perspective, it is the wrong way of
looking at the problem, as it just clutters up the engineering
and leads to pointless debates and confusion.  (However, it
*does* have value from an academic perspective, as it fills in
the logical formalisms that explain how this all works in the
case where a client chooses to believe a set of RDF statements
from the web.  And eventually such analysis will lead to the
same architectural conclusions, but that's a very long and
torturous route around the lake to get to the beach next door.)

 From an architectural perspective, "meaning" and "truth"
are the *wrong* goals -- the *wrong* metrics for judging the
semantic web architecture.  The important metric is *usefulness*
to applications.  And that is inherently *relative* to each
application.  The goal overall is to maximize total usefulness
to the community.

The basic requirements behind issue-57 and the httpRange-14
rework are:

  1. There must be a standard, algorithmic way for a client,
  given a target URI, to find the URI owner's implicit or
  explicit *definition* for that URI.

  2. The URI owner must be able to provide an arbitrarily
  detailed definition (though not necessarily for a URI of
  every possible syntactic form).

  3. In the case where a URI owner has served a page with
  no explicit URI definition, the algorithm must specify an
  implicit definition (though possibly empty).

Of course, there are many other motherhood-and-apple-pie
requirements as well, such as graceful degradation in the face
of inconsistencies, ease of use, general utility, and harmony
with the rest of web architecture.  And in deciding what the
implicit definition should be, a key consideration is to weigh
the cost/benefit trade-offs between URI owners and clients,
to figure out what would best benefit the community overall.
Some of the proposals we've seen essentially advocate an empty
implicit definition; others advocate implicit definitions with
varing levels of content.

Bottom line: We'll get a lot farther a lot faster if we
forget about trying to define either meaning or truth, and 
simply focus on definitions and usefulness.


-- 
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 Friday, 30 March 2012 20:10:15 UTC