Re: Relationship Taxonomy Questions

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

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

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

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

| presumption is based in part on the opinion that typing links is in fact a
| useful thing to do for some types of information.

"presumption," "unproved," "opinion."  I decline to share your premises
because I can't figure out what you're saying.

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

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

As I answered No to 1, I regard this question as irrelevant.  

| 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?

Same response.

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

No.

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

Cart before horse.  The syntax serves to enable behavior; behavior should
be established first.  The linking discussion started off with a consideration
of behavior, let's get back to it.  We had inclusion, transclusion of
parts, traversal, and one or two other items I don't see mentioned below.
That's the work our links have to do; I have seen almost no discussion
of how this work is to be done, concretely, in an interoperable way.

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

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.

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

"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 links.  
Were you asking questions or giving the answers?

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

Now I'm completely confused about what you think a relationship
type is.  Why is all this prose necessary to ask what started out
as a simple question?

| 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 what type?  How did you arrive at this generality?

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

Pardon me if I sound testy, but linking doesn't have to be discussed in
the impenetrable way it has been on this list the past month.  Please
try again, Eliot.


Best regards,
    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Wednesday, 22 January 1997 15:41:28 UTC