[forwarding] Topic Maps paradigm makes URI signification straightforward

The attached message is from Steve Newcomb <srn@coolheads.com>.

-- 
eric miller                              http://www.w3.org/people/em/
semantic web activity lead               http://www.w3.org/2001/sw/
w3c world wide web consortium            http://www.w3.org/

To: www-tag@w3.org
Message-Id: <B454CFF8-281E-11D7-92BC-000393753936@apache.org>
Subject: Topic Maps paradigm makes URI signification straightforward
From: "Steven R. Newcomb" <srn@coolheads.com>
Date: 16 Jan 2003 14:41:58 -0600
Lines: 261

***************************************************
*                                                 *
*  This is my second attempt to post this         *
*  message.  I know my first attempt (on Jan 16)  *
*  was received, because the W3C system asked me  *
*  for my permission to archive, as a             *
*  prerequisite to posting.  I gave my            *
*  permission, and the system assured me that my  *
*  posting was now published.  But it wasn't, at  *
*  least not as far as I can tell.  Sorry for     *
*  any repetition.                                *
*                                                 *
***************************************************

I think I can answer the question:

  What does the HTTP significance of a URI have to do
  with its significance in terms of RDF [see footnote
  1]?

...and I'm willing to answer it because, as a
side-effect of reading my answer, you, dear reader,
may learn a thing or two about ISO Topic Maps.

Things get simpler if we recognize that everything that
we talk about, without exception, is a subject (as in
"subject of conversation").

Much of the confusion about URIs stems from the fact
that we seem determined to avoid recognizing that every
URI is itself a subject, that every Resource is a
subject, that everything in a cache is a subject, etc.
In fact, every signifier, and every other piece of
information, qua piece of information, is a subject,
independent of any subjects that it may be used to
signify.

And then, of course, there are the subjects that we
*want* to talk about, which are, very often, *not*
pieces of information.  In order to break myself of bad
thinking habits that were leading me in circles, I have
found it useful to say to myself:

  "There are two kinds of subjects: 

  (1) subjects that are pieces of information (which
      may be signified by other pieces of information),
      and

  (2) subjects that are *not* pieces of information
      (which *also* may be signified by pieces of
      information)."

It's an error -- because it can only cause confusion --
to fail to acknowledge the full stature of the
subject-ness of a piece of information, such as a URI,
merely because we are determined to regard it solely as
a means of signifying another subject (or, as the case
actually is, some set of other subjects).  Every
signifier (every name, every resource used as a
signifier of anything) is, necessarily, ipso facto, a
subject in its own right.

Here are three thoughts:

(1) Subjects are the main things.  Whenever we
    communicate, we must try to hitch our wagons
    directly to the subjects, and try to find ways to
    avoid getting hung up on their signifiers.  (Always
    remembering, of course, that signifiers are
    subjects, too, in their own right.)

(2) Relationships between subjects are also subjects.
    We mislead ourselves whenever we fail to
    acknowledge a relationship, when one necessarily
    exists (even if only implicitly) in our discourse.

(3) Whenever a subject has a signifier, there are no
    fewer than three [see footnote 2] subjects
    involved:

      (i) the subject that is being signified,

     (ii) the signifier of the subject, and

    (iii) the relationship between the signifier and
          the signified.

With these thoughts in mind, let me paraphrase Roy
Fielding's statement:

  "There exists a time t at which GET(URI, t)
  yields representation r."  

  (Yes, I'm ignoring the ambiguity of the nature of r
  due to language negotiation, etc.  Please bear with
  me; that's just a detail for purposes of this
  discussion, and it will become obvious how to deal
  with this detail in a moment.)

In the above statement, there are at least three
subjects:

  (i) the representation returned by the GET,

 (ii) the URI, and

(iii) the relationship between the URI and the
      representation that is yielded by a GET at time
      t.

Or, better, we might separate the GET semantic from the
time t semantic, giving t its own role type:

  (i) the representation returned by the GET,

 (ii) the URI,

(iii) time t, and

 (iv) the relationship between the URI, time t, and the
      representation yielded by a GET.

  (Yes, a time of day is a subject.  Remember:
  everything we can talk about is a subject.  Subjects
  are our *only* focus, here.  We must preserve our
  ability to say anything about any of them, and we
  benefit greatly if we do not allow ourselves to talk
  -- at all -- about anything that we don't regard as a
  fully-privileged subject.)

In the above example, the assertion type is, in fact, a
function that is a specific perspective in which the
URI has a specific meaning.  The meaning is "yielded"
by the assertion in the form of the node that plays the
"representation" role.  

  ("Node" == "topic", in the jargon of topic maps.  A
  node (or "topic") is a proxy for a subject.)

The type of the assertion makes it absolutely clear
that the player of the "representation" role is what is
yielded by a GET on a specific URI at a specific time.
Therefore, the player of the "representation" role is,
by definition, a piece of information, qua piece of
information, because that is what a GET always yields.

But what if I want to utter the URI with the intent of
using the *representation* yielded by a GET on that URI
as a *signifier* of some *other* subject?

Here is where the power of the Topic Maps discipline
[see footnote 3] begins to get interesting.  We can
have another assertion type, one that has two role
types:

(1) a subject which is a Piece Of Information (let's
    call it the "POI" role type), and

(2) the subject that is signified by the piece of
    information that plays the "POI" role type (let's
    call it the "indicatedSubject" role type).

Each instance of this assertion type acts like a
function; it takes the piece of information (such as
the piece of information that was yielded by our first
example), and yields the subject signified by it.  A
human being may form part of the platform on which the
function runs.  

When we define such an assertion type, we may provide
additional role types that are played by subjects that
are hints to the human being about how to interpret the
piece of information, and/or rendition instructions to
the system that renders the piece of information for
human perception.

It's just a different kind of signification
relationship.  And, it *depends* on the GET
signification relationship that we discussed earlier.

***

There's nothing really new in any of the above.  My
point, basically, is that it's much simpler to think
about and talk about these questions, if you first
admit that:

* signifiers are subjects, 

* signification is a relationship between signifier and
  signified,

* relationships are subjects,

* there is an unbounded number of kinds of
  signification, and each kind may have any number of
  governing parameters, each of which is a subject,

* certain kinds of signification (such as GET) are
  already well known, understood, and quite rigorous,
  so we might as well honor them by representing them
  as assertion types that yield subjects, in exactly
  the way that they really, really do, and

* all other kinds of signification *also* need to be
  made fully explicit, even (and perhaps especially) if
  they require the application of human intelligence.
  For example, the semantics of a particularly annoying
  assertion type could be expressed in pseudocode as
  follows:

  -- Before allowing a human user to make an assertion
     in which the node that plays my "indicatedSubject"
     role type plays any role,

     (1) make sure the human being knows English and is
         perceiving what's being rendered for him/her,

     (2) using stylesheet XYZ, render the Piece Of
         Information that plays the "POI" role, and

     (3) wait until he or she acknowledges that he or
         she understands the subject that is being
         indicated.


-------------------------------------------------------
Footnotes:

[1] The draft Reference Model for ISO 13250 Topic Maps
    shows how to represent all Topic Maps in RDF using
    eight specific kinds of RDF statements.  See
    http://www.isotopicmaps.org/tmmm/tmmm-latest.html#parid0022

[2] Actually, in order to allow knowledge to be
    self-describing, and in order to permit knowledge
    to be merged and managed losslessly, and without
    redundancy, the draft Reference Model of ISO 13250
    Topic Maps acknowledges the existence of eight
    distinct subjects whenever a relationship exists
    between two subjects.  Three more subjects are
    added for each additional role type that is played
    in the relationship.

[3] Three important features of the Topic Maps
    discipline:

      In a "well-formed" topic map:

        (1) Every subject that is uttered or implied by
            any utterance has at least one explicit
            proxy (a "node", a "topic").

        (2) Every node is the proxy of exactly one
            subject.

      In a "fully-merged" topic map, in addition to
      the above:

        (3) No subject has more than one proxy.

-- Steve

Steven R. Newcomb, Consultant
srn@coolheads.com

Coolheads Consulting
http://www.coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA