Anchor terminology

[Lee Quin:]

| I think my first comment is that I have a real problem with the
| terminlogy.  I know it's very HyTimesque to talk about a link end as
| being something that's not actually in a document, and also to talk
| about link ends as having anchor roles.  But only anchors can have
| anchor roles -- obviously :-) -- and link ends ought to be what you
| find at the end of links, when you follow them.

Yes.  I thought that we had this settled a few weeks ago.

The terms "anchor", "link-end", and "anchor role" are so confusing as
to make the current specification almost unreadable for this
non-HyTime expert.  And I cannot believe that what I am experiencing
is much different from what the majority of our audience will
experience.

Let's think about a piece of rope.  Suppose I lay a length of rope out
before you, point to its terminations, and ask you what they are
called.  If you are a speaker of English you will say, "Those are what
we call the *ends* of the rope."

Now suppose that (for some unimaginably perverse reason) I wish to
call the extremities of the rope "anchors".  You will say, "Well, you
may have good reasons for not using the word 'end' (though I can't
imagine what they are), but your choice of the word 'anchor' is very
confusing, because an anchor is something that *can* be at the end of
a rope, but only if someone puts it there.  Every rope comes with two
ends, but the anchor is an optional feature found only at the ends of
certain particular ropes."

So the first confusion is that you are using the word "anchor" where
any native speaker of the language would use the word "end."  The
second confusion is that you have now denied me the ordinary use of
the word "anchor" to mean something that can only come at the end of
certain ropes if someone deliberately puts it there.  Since I don't
have that term anymore, I will have to invent one, and whatever I
invent ("explicit anchor", "labeled anchor", etc.) will conflict with
the usual term.

The third confusion is the use of the term "link-end" to mean not what
any normal person would call the link end, but rather the
specification of a link end.  Conflating the thing and the
specification of the thing is about as basic as confusion gets.  This
is the territory; that is the map.  Not the same thing.  Different.

Since I can't really continue into the specification using the current
terminology without becoming dizzy and ill, I've stopped and rewritten
the terminology section using words that make sense to me.  "Anchor"
becomes "link end", "link-end" becomes "end-spec", and "anchor role"
becomes "end role".  As a side benefit of this exercise we get the
very useful word "anchor", which by a marvelous coincidence ends up
meaning what everyone who is not a HyTime expert already thinks it
means.

   1. link end: Anything which happens to be reachable by traversing
   a link. In principle, every piece of data may be a link end.
   Individual link ends may sometimes be made up of an aggregate of
   objects considered to be a single object for purposes of the link.

   2. anchor: an element specifically designed to serve as a link
   end.

   3. link: A data object that explicitly represents a relationship
   between two or more link ends. A link has a link type, which is a
   name intended to communicate the overall significance of the
   relationship.

   4. end-spec: The part of a link that specifies one of the data
   objects that serve as the ends of the link. Each end-spec has a
   type called an end role that identifies the conceptual function of
   that end in the relationship that the link expresses.

   5. locator: The means by which an end-spec specifies where a link
   end resides. This may be as simple as a URL, ID, or query, or it
   may be a complex chain of relative pointers that eventually lead
   to a collection of discontinuous data portions that together make
   up the link end.

   6. explainer: A caption associated with an end-spec that is
   suitable for showing users as a means of explaining the
   significance of the link end [not end-spec]. If there are many
   links of the same type, the explainer might or might not be the
   same for all the link ends [not end-specs] with the same end role.
   [N.B.: ends have roles.  End roles are specified in end-specs, but
   the things that have roles are the ends, not the specs.]

   7. traversal: The action of using a link; that is, of accessing
   one or more link ends from one or more other link ends. Traversal
   is usually considered a user action (commonly initiated by
   clicking on a displayed link end), but it can also occur under
   program control.

   8. bi-directional link: A link that can be traversed starting at
   more than one of its ends.  Note that being able to "go back"
   after following a one-directional link does not make the link
   bi-directional.

   9. in-line link: A link whose representation occurs at one of its
   ends, which is always an anchor [note the distinction]. HTML <A>,
   HyTime clink, and TEI <XREF> are examples of in-line links. Such
   links are inherently one-directional, because there is nothing at
   the other end to indicate that a link necessarily applies.  [I
   think that "necessarily" is required here.]

   10. out-of-line link: A link whose representation does not
   necessarily occur at one of its ends.  Such links only make sense
   given a notion like link databases, where applications know to
   look for links. Nevertheless, out-of-line links are required to
   support bi-directional traversal and for creating links with ends
   inside read-only data objects.

I have deliberately taken a lot of liberties here in order to
distinguish misunderstandings of my own from problems with the
terminology.  If I've gotten this wrong I will now learn something,
whereas with the previous terminology I wouldn't have understood the
correction.

Jon

Received on Monday, 27 January 1997 23:56:20 UTC