Re: Relationship Taxonomy Questions

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

I agree.

> First, we have some basic structural relationships:
> 
> 1. Hierarchy.  In SGML, hierarchy is *completely* defined by element 
>    structure.

Well, I would say by containment rather than by hierarchy.
Hierarchy is one possibly but not I think mandated interpretation
of containment (at least not mandated by ISO8879:1986).

> 2. Content of.  In SGML, content relationships are represented by containment.

I think this is a tautology, but agree that it is a relationship.

>    In this model, "transclusion" is a "content-of" relationship, possibly
>    expressed through use-by-reference ("content location" in HyTime terms).

I don't agree with that at all.  Transclusion is a means of presentation,
and has nothing to do with the semantic relatioonship of the other end
of the link.
I might want to say
    Transclude (show inline) all of Eliot's comments marked as DISPUTATION
    but leave only external pop-up link icons to Eliot's AFFIRMATION links,
    as I don't need to read those right now.

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

The presentation style is transclusion if you use it and not if you don't,
I think.  Xanadu gave/gives the user no choice but transclusion, so many
people read Nelson as meaning that transclusion means mandatory presentation,
but I am not sure that that's fair.  It would be better, I think, to say
that Ted Nelson says that transclusion is compulsory.  But I have never
met him. and have no idea whether he would in fact make such a distinction.
<digression>He carries a camera with him everywhere, and somewhere
probably still has film of a conversation he had with Yuri.</digression>

> 3. Property of.  In SGML, properties of elements are usually represented
>    by attributes of elements, although they may be represented by 
>    subelements.

Of course, not all attributes are best thought of in that way, and not
all properties are so represented in practice.  For example, most SGML
systems implement some form of #INHERITED for styles (as does DSSSL) even
though SGML lacks this feature.

>    The distinction between properties and content is somewhat blurry

The O-O approach might be to say that the content is a properrty of the
element.  Mathematically, there is no difference between an attribute and
content except that the meaning of markup within SGML attributes is not
well defined, and they don't nest properly.  Since SGML software often
has restrictions on what you can put in or do with attributes, I have a
rule of thumb that says that all displayed content should be content,
not attributes, but I break it fairly often.

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

That is certainly not true in an SGML editing program -- a single processing
session might include an attribute changing value, perhaps automatically
(e.g. being assigned an ID, or today's date) or being created or deleted.

An element might be moved.  If you were using a complex DSSSL specification
that said that the first paragraph of each chapter appeared in the Overview
section and not the actual chapter, inserting a paragraph at the start of
a new chapter in an editor might be very disconcerting :-)

You omitted the "followed by" relationship that is generally considered
important in SGML, even if it isn't actually required by the standard
(I think it probably is, but I am not sure): that the order of subelements
ontained in a given location is significant, even if all the elements
match the same GI in a content model.

In other words, given
    <!Element Class (teacher, boy+)>
    <Class><Teacher>Mary</Teacher><boy>Laurence</boy><boy>Barney</boy></Class>
I can't shuffle the boys around and still conform -- there is an implicit
"followed by" relationship between Laurence and Barney.  Perhaps they are
arranged in order of age, for example.  Or in order of height.  Or in
reverse alphabetical order.  A browser that displayed this as
    Mary:
	Barney
	Laurence
would not be observing this relationship very helpfully.
Sorry for stressing this so much -- I see it overlooked so often!
A relational model does not have such implicit ordering, so that if
you store SGML in a database (or HTML or XML), one element per "cell",
you have also to store the ordering relation explicitly.

Finally, note that SGML entity structure and marked section structure
can break the SGML hierarchy -- you can do
    <!Entity start-class "<Class><Teacher>">
    <!Entity pupils "</Teacher><boy>">
    <!Entity and "</boy><boy>">
    <!Entity end-class "</boy></Class>"
    &start-class;
	Mary
    &pupils;
	Laurence
    &and;
	Barney
    &end-class;

(well, that's a rather small class, but you get the idea)

> 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      Resemblance       Difference        Annotation
> Aggreement        Disagreement      Constrast         Ownership
> Connection        

Please _do_ see the draft that Murray and I wrote.  If he isn't totally
snowed under by e-mail, I am sure Steve DeRose can give us some references
on this stuff too, and there's also literature on the subject of labelling
parts of formal discourse, as well as Aristotlean Causes and other sorts
of annotations.

> 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.
What if your hyperdocument is contained in multiple SGML documents, perhaps
not all sharing the same DTD?

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

It's also rather like inclusion by use of syntactic entity references,
    <!Element big-class SYSTEM "http://&myserver;/class-311.list">
    <Class>
    &big-class;
    </Class>

Lee

Received on Thursday, 23 January 1997 15:25:57 UTC