W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > January 1997

Re: Relationship Taxonomy Questions

From: W. Eliot Kimber <eliot@isogen.com>
Date: Wed, 22 Jan 1997 17:25:14 -0900
Message-Id: <>
To: Terry Allen <tallen@fsc.fujitsu.com>, w3c-sgml-wg@www10.w3.org
At 12:41 PM 1/22/97 -0800, Terry Allen wrote:
>Eliot purports to ask a set of questions:
>| The questions:
>| Assuming that there is a distinction between link behavior and the
>| relationship types that links represent, and in particular, a distinction
>| between behavioral "primitives" and relationship "primitives":
>In view of the definitions below it's hard to say whether this
>assumption is warranted.  And you never define "primitives."

You're right, I didn't.  I think by primitives we mean either discrete
building blocks that are combined to form complete wholes (e.g. "style
primitives" such as font size, color, family, slant, etc.) or, in the case
of types, fundamental taxonomic types or classifications ("archetypes?")
from which more specific types can be derived.  We discussed the
possibility of "relationship primitives" that would be combined to create
new types, but Steve D. convinced us it was not tractable (and quite
possibly not useful), at least in this forum.

>| 1. Is it necessary or useful for XML to define some finite set of
>| well-defined relationship types or primitives?  
>Assuming you mean something straightforward, no.  Defining
>the semantics of relationships is not for a metalanguage.

You always have to define some level of semantics--even SGML defines the
semantics of "markup" and "data", "element" and "attribute".  However, many
of us feel XML needs to also provide at least a little bit of semantics in
the form of an architecture for the representation of very common
constructs, possibly including some sort of "starter set" document type
that people can use immediately to create documents without having to also
engineer style sheets and so on.  Defining such a starter set doesn't
preclude the use of any other document types, it simply makes the cost of
entry lower for those for whom the starter set is sufficient.

>| Our presumption, as yet unproved, is that the interoperation of XML
>| documents within some general purview (e.g., the Web, as opposed to
>| domain-specific purviews, such as a particular intranet) requires some
>| basic set of link types whose meaning is well defined and understood.  This
>What's a link type as opposed to behavioral and relationship primitives?
>What is the "meaning" of a "link type"?  For that matter, what is a
>"link type"?  Please give simple examples.  

A link type, as indicated above, is a relationship type (at least in this
proposed model of link representation).  The two are synonymous, because
links represent relationships.  The meaning of a type is the description of
the relationship.  

If I have a link type of "foo", you have no idea what it means.  But if I
say a foo relationship associates a pet to its master in order to express
ownership of the pet by the master, then you know that foo means "owned by"
(or "owns" or "ownership"--however you prefer to state these things).  If I
then say I have another relationship "bar" that associates pets with their
trainers, you know that a "bar" relationship means "trained by".  I have
defined two relationship types ("foo" and "bar") and defined their
semantics ("ownership" and "instruction").  

In XML, these relationships might look like this:

<foo owner="http://www.drmacro.com/vanity.html"
     pet="http://www.drmacro.com/forrest.html">A boy and his dog</foo>
<bar trainer="http://www.drmacro.com/vanity.html"
     pet="http://www.drmacro.com/forrest.html">Bassets are headstrong and
hard to train.</foo>

I then realize that not just pets are owned and instructed, so I decide to
generalize these concepts and refine "foo" to mean simply "owns" and "bar"
to mean simply "instructs", partly because I want to distinquish my
relationship to my dog (who I both own and train) and my students, who I
train but don't own.  I further specialize my relationships by adding
distinct roles.  In the generalized "foo" relationship, the roles might be
simply "owned" and "owner".  In the "master-of" relationship, derived from
foo, the roles might be "pet" and "master".  If I know "master-of" is
derived from "foo", I can tell that master-of is a kind of ownership
relationship and that the pet must be the thing owned (because it
corresponds to the supertype role "owned") and the master must be the
owner.  I might express this like this:

<!--* Relationship type definition document *-->
 <RelType name="foo" roles="owner owned">Relates owners of things to the
things they own.
 <RelType name="bar" roles="instructor student">Relates instructors to the
beings they instruct (their students).
 <RelType name="master-of" derived-from="foo"
          roles="master pet">Relates people (masters) to the pets
they own.

<!--* A document that uses these relationship types *-->
<MyDoc base="http://www.drmacro.com">
<h2><title>Stuff I own</title>
 <foo typedef="mytypes.html#foo" 
      owner="vanity.html" owned="../media/explor2.gif"/>
 <master-of typedef="mytypes.html#master-of" 
            master="vanity.html" pet="forrest.html"/>

Note that all of this discussion has *nothing* to do with behavior.  When I
actually create a document relating pets to owners, there are any number of
behaviors I might want associate with the different types and roles,
depending on my mood, the user of the information, etc.  But the behaviors
don't change the nature of the relationships described.

>And please leave out the red herring of an intranet; it will operate 
>on the same architectural principles as the Intranet.

I simply meant that on the Internet, you can't generally predict who will
be accessing your information, nor can you expect people to look at the
copious documentation on your carefully-crafted relationship types.
However, within an intranet, the information may support a specific
business process where the relationship types are both well understood and
critical to the use of the information (things like resource-to-project
relationships, enterprise organization relationships, domain-specific
relationships (chemicals to products to safety regulations to customer

The underlying infrastructure architecture may be the same, but the uses to
which that instrastructure will be put are, I think, fundamentally
different much of the time (and one of the reasons that I think intranets
are where XML will really shine and where the big money is to be made with
all this stuff--right Len?)


>| We take it as a given that the set of possible relationship types is
>| unbounded.
>So obviously no subset of them will be satisfactory, and we need a
>general way to refer to them, whatever they are.  

No classification scheme can ever be complete.  We're only wondering if
it's necessary or useful to build the beginnings of one for link types.
[The presentation I enjoyed most at last year's Hypertext conference was
the closing keynote by the woman who described her research into the
sociology of classification.  The basic messages were "every useful scheme
needs an 'other'" and "every classification exercise has political and
social implications and constraints".  Since SGML (and by extension, at
least in my world, hyperlinking) are mostly about defining classification
schemes, I found this presentation very enlightening.  I recommend hunting
up the proceedings and reading it.  I'd provide a citation if I knew where
my proceedings were.]

>Cart before horse.  The syntax serves to enable behavior; behavior should
>be established first.  

We (the ERB) don't agree.  Our feeling is that behavior and syntax are
independent.  Because many applications of XML will need the semantics but
will provide their own behavior specification mechanisms, we feel that
doing semantics first is the proper order.

For example, given an XML-defined way to describe link semantics, I can
figure out to translate that into HyTime terms and provide the resulting
documents to Panorama, HyBrowse, and DynaText, all of which provide their
own mechanisms for defining behavior.  Therefore, XML's definition of
behavior is largely irrelevant to any use I might put XML to in the near
term, but link types are not.

>|     In the SGML model, behavior can be considered an aspect of "style" or
>|     presentation and may be defined explicitly through "style sheets" or
>|     "processing specifications" or may be embedded into a particular
>|     browser or processor (e.g., HTML browsers pre CSS).  In this broad
>|     definition of the term style, mechanisms such as scripts, controls,
>|     and plug-ins could all be considered aspects of style specification.
>Or may be specified in a DTD or by labelling with well known semantics.
>This is not a real useful definition of behavior.  "Generally regarded
>as poor practice" is your view, and you should label it as such. 

>|     At this point we are assuming that behavior will be specified both in
>|     some normative way in an XML specification and, at user option, through
>|     some as-yet-undetermined behavior specification system or systems (e.g.
>|     "link style sheet").
>Eh?  the user gets to change the behavior of the links in the document I
>sent him?  That's a new one.  Though perhaps your overbroad definition
>of behavior renders the issue moot.

The only way you can *ever* ensure a particular behavior for a document is
to render it through a closed system.  As XML is designed specifically to
enable the networked interchange of documents, any energy spent worrying
about users changing behavior of presented documents is wasted.  If you
want "my way or nothing", use Acrobat.

>"Poor practice" is religion, Eliot.  One can argue just as well that on 
>the Internet your system will work best if it does not depend on typed
>Were you asking questions or giving the answers?

Didn't I say that untyped (or rather, links with uselessly general types)
links are fine when that's all you need?  "On the Internet" is meaningless.
 You can only evaluate data with respect to the uses to which it is put.
The Internet is a delivery infrastructure and implies no use scenarios
whatsoever.  When I'm pulling down finding aids from the Duke University
Library over the Internet, I care very much that they've gone to great
effort to create documents with rich semantics and typed relationships,
because that information is intended to help me retrieve efficiently.  When
I'm pulling across the visual noise of  the cool site of the hour, I don't
care at all.  We need typed and untyped links, always have, always will.

>| semantic
>|     The "meaning" associated with a type.  The term "semantic" is dangerous
>|     because it is overloaded and can mean different things in different
>|     contexts.  In this discussion, we are trying to clearly differentiate
>|     meaning, which is abstract, from behavior, which is concrete.  In
>|     there is a one-to-one relationship between a type and its semantic, but
>a what type?  How did you arrive at this generality?

It's the freakin' definition of type: a label for a set of semantics.  Or
would you prefer a Dadaist approach to type definition?


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 Wednesday, 22 January 1997 18:57:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:06 UTC