Relationship Taxonomy Questions

All,

The ERB would like to ask the list to address the following questions
relating to relationship (link) typing.  

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":

1. Is it necessary or useful for XML to define some finite set of
well-defined relationship types or primitives?  

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
presumption is based in part on the opinion that typing links is in fact a
useful thing to do for some types of information.

We take it as a given that the set of possible relationship types is
unbounded.

2. If the answer to question 1 is "yes", what is the list of types?

3. Given such a list, 
   A. can these types be considered to be a set supertypes from which new
types
      may be derived?
   B. If so, what mechanisms could or should be used to define such a class
      hierarchy?

4. Is there a preferred formalism, in terms of prose rhetoric, formal
notation, or both, by which the meaning of relationship types should be
expressed.  NOTE: this formalism *cannot* consist only of behavior
specification (although it may include a behavior specification).

NOTE: The issue of behavior primitives is not open for discussion at this
time.  The behavior issue will be taken up after the base link
representation syntax and link typing issues have been sufficiently resolved.

Definition of terms:

behavior
    What happens when some agent interacts with the
    link, either directly or by interaction with one of its link ends.
    Behavior includes all of what happens in user interfaces, and could also
    include behaviors of translators, processors, query engines, etc.
    In the general case, behavior is not permanently (and exclusively)
    bound to data objects (i.e., the SGML content vs. style model).  However,
    some element types or base element type classes may have semantics
    that largely or exclusively suggest a particular behavior (e.g., <font>),
    although it is generally regarded as poor practice for most applications
    (partly because implementation of the suggested behavior cannot be
    universally enforced). 

    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.

    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").

relationship
    A *semantic* association among two or more objects intended to describe
    the nature of the assocation.  Relationship types may be thought of as
    analogous to element types in SGML, such that where element types
    classify data objects, relationships (and thus links) classify 
    assocations among data objects.  Like element types, relationship
    types can range from the very general ("linked") to the very specific
    ("Counterargument").

    Our assumption is that links always represent relationships of some
    defined (albeit possibly very general) type.  In the likely syntax
    design model, the link type will be named either through the element
    type of a link element or through an attribute that defines the type
    name.

    Relationships are distinguished by relationship type.  In addition,
    some relationship description models may further describe relationships
    by naming the roles in the relationship (e.g., the HyTime hyperlink
    model).  As for element types, some relationship types may largely or
    exclusively suggest a particular behavior (e.g, <goto>).  Such
    relationship types are poor practice only when their use fails to
    identify a more specific relationship type that would enhance the value
    of the information in the scope of its expected application and use
    (in other words, when you don't care about the link type, there's little
    value in being more specific than "link", but if your system expects
    and depends on typed links, you'd better type them).

    Relationships may be implicit in the data structure (i.e., the
    hierarchical relationships defined by SGML markup) or explicit through
    hyperlinks or other associative systems (i.e., relational databases).

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 general,
    there is a one-to-one relationship between a type and its semantic, but
    a one-to-many relationship between a type and its possible behaviors.
    In other words, a type's semantic doesn't change, but that semantic may
    be interpreted into specific behaviors in a variety of ways depending on
    the use to which the type is put or the arbitrary whim of the behavior
    specifier.

Cheers,

Eliot.



--
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 14:24:54 UTC