Re: Relationship Taxonomy Questions

At 08:26 AM 1/23/97 -0800, Terry Allen wrote:
>Eliot:
>| All we're saying is that we don't want XML's link representation scheme to
>| be *limited* to behavior-only links.  We also recognize two facts:
>
>What you were saying is that you want to specify a set of relationship
>labels.  I think the taxomony of relationships is orthogonal to the
>mechanism for using them, and competition among different taxonomies
>should be encouraged, hence XML itself should not specify a
>taxonomy.

I don't see how the conclusion of the last statement necessarily follows
from its beginning. I would say, with as much conviction:

"I think the taxomony of relationships is orthogonal to the
mechanism for using them, and competition among different taxonomies
should be encouraged, hence XML itself should specify a
taxonomy with which others can compete."
  
>You have not given a single example of a label you want to specify.  
>Please do so.

Ok, here's my personal approach to this problem.

First, we have some basic structural relationships:

1. Hierarchy.  In SGML, hierarchy is *completely* defined by element 
   structure.  In other words, a document is first and foremost a
   hierarchy of elements.  NOTE: some elements may refer to their 
   content by references to other entities (e.g., subdocuments).
Nevertheless,
   the hiearchy is represented by the structure of the elements.

   [Before you say that SGML doesn't require it, it does if you apply the
   principle that if a standard provides a facility
   for something you should use that facility exclusively {a principle that
   I know from previous conversations Terry doesn't agree with},
   then the above statement is definitely true.  In any case, the above 
   statement is a principle of the HyTime design, for good or ill.]

2. Content of.  In SGML, content relationships are represented by containment.
   This containment may be syntactic (the stuff between start and end tags)
   or by reference (reference from an element to another data object
   designated as containing its content).
   
   In this model, "transclusion" is a "content-of" relationship, possibly
   expressed through use-by-reference ("content location" in HyTime terms).

   Note too that I'm making a distinction between "required transclusion"
   (which is what I think Terry means by the term) and a presentation 
   style that happens to present one anchor at or in place of another anchor.
   The latter is not transclusion in the strict sense that I use it here
   and that I think it is meant by T. Nelson and Terry.  This is one reason
   why HyTime distinguishes content location from hyperlinks: they differ
   in their degree of required processing.  Transclusion says "this is my
   content just as surely as if it had occurred here directly" while
hyperlinks
   say "go here or don't, I don't care".

3. Property of.  In SGML, properties of elements are usually represented
   by attributes of elements, although they may be represented by 
   subelements.  Like content-of relationships, properties may be used
   by reference.  Properties are characterized by being non-optional or
   otherwise essential to the interpretation of the object: take one away
   and you have a new object.  [The distinction between properties and
   content is somewhat blurry, although it seems to be a useful one, at
   least for document representation.  Obviously, it's up to a particular
   schema definition to define what are "properties" and what is "content".]

These three relationship types are "priviledged" types in the sense that in
SGML they have optimized syntaxes for their representation and are
generally considered to be static properties of the objects that exhibit
them.  Of course, the term "static" doesn't mean "written in stone", it
just means "stable over the period of a single processing session", however
"processing session" is defined (might be a millisecond or millennium
depending on the application).

Thus the above relationships are distinguished from "hyperlink"
relationships by being both priveledged and, generally, non-optional, in
that you must resolve the above relationships in order to understand the
data  (e.g., produce a static rendering of it).

All other relationships are "hyperlinks" in that they:

1. Do not define purely hierarchical relationships (parent, child,
containment)
2. Are "optional" in that they need not be processed and the failure to
   do so will not change the basic meaning of the data.
3. Are generally intended to enable interactive traversal or retrieval of
   the data (but may be intended for other purposes as well, such as the
   control of processing for some specific output or the representation
   of relationships that are never directly exposed to the user).

Given that, what would I consider to be a useful starter set of
relationship types in the domain of general web delivery of general
information?  How about:

- Similar-to
- Different-from
- Background-for
- More-information
- Citation-of
- Annotation-of
- Aggrees-with
- Disagrees-with
- Contrasts-with
- Supplier-of
- Source-of
- Owner-of
- Connected-to ("semantic-less" link, e.g., "A")

These are all link types that would be useful to use with contextual links
because they provide some clue about why the link connects where you are
(or what it names in its content) to whatever it links to.  I'm sure there
are more I could think of if I cared to spend more time at it.  I have
chosen relationship names that imply a directionn mostly because contextual
links usually have a directional nature (though they need not).  Some these
require a directionality because they are not reflexive (background-for,
Citation-of), others are reflexive.

If I was designing the reflexive versions primarily as independent links, I
might use these names:

- Resemblance
- Difference
- Annotation
- Aggreement
- Disagreement
- Constrast
- Ownership
- Connection

I have not included any "structural" link types because they aren't useful
or necessary. The use of crafted hyperlinks purely for navigation purposes
is unnecessary in this model because the purely navigational relationships
(traversal of the hierarchy or among semantically-distinct parts of the
hyperdocument) are inherent in the hyperdocument's structure.  In other
words, if you use SGML element structures to represent all hierarchy,
you've done everything you need to do to enable the generation of whatever
navigation aids you need (witness DynaWeb)--the only limiting factors are
the presentation facilities of your tools and your implementation resources.  

This is not to say that a system of non-structural hyperlinks might not
happen to be organized into a hierarchy, but that is a different
application of hierarchy, distinct from the task of organizing the core
content (the data to which the hyperlinks are applied).

Note that by using content by reference (transclusion or content location,
whichever you prefer or hate the least) you can apply new hierarchies to
existing data, but in a way that is not hyperlinking as I've defined it
above. 

Cheers,

E.
--
W. Eliot Kimber (eliot@isogen.com) 
Senior SGML Consulting Engineer, Highland Consulting
2200 North Lamar Street, Suite 230, Dallas, Texas 75202
+1-214-953-0004 +1-214-953-3152 fax
http://www.isogen.com (work) http://www.drmacro.com (home)
"Rats in the morning, rats in the afternoon...if they don't go away, I'll be
re-educated soon..."                 --Austin Lounge Lizards, "1984 Blues"

Received on Thursday, 23 January 1997 13:11:39 UTC