Re: Relationship Taxonomy Questions

W. Eliot Kimber wrote:
> 
> At 08:52 AM 1/23/97 -0600, Len Bullard wrote:
> 
> >Those are application systems, not "purviews".  One has a range of
> >applications which currently interoperate based on the use of the URL
> >specification and predefined schemes which in practice, work out to
> >be network protocols.
> 
> Len and I are using the term "application" in different ways.  

Third person.  Yo!  Over here!

> By "application" I mean it in the SGML and database sense, meaning a
> collection of data of specific types and semantics to which processing is
> applied, rather than the processors themselves.  If I understand Len's use,
> he means the actual system used to implement the application. 

I meant "The Web".  It is a system used on the Internet for hypermedia.
There are others but they don't have quite it's level of acceptance.

> Many
> programmers don't make a distinction between these two uses: the software
> is inseparable from the data in their mind.  But this is a self-defeating
> mindset because data tends to outlive software, thus binding data to
> software to closely ensures the obsolescance of the data.

Can be true, but do read the stuff at the bottom of the message, that 
is, what a *programmer* means by data object, data structure, etc.
 
> >Within a given application framework,
> >inter-object
> >messaging is provided by the API for that framework.... err.. messages
> >and
> >functions.
> 
> I think there's a basic disconnect here.  The purpose of XML is to define
> *data representation languages*, not functional ("programming") languages.

Ok.  SGML- - instead of HTML ++.  But this is not a disconnect.
Posting the MID example was really just a way to say, all of the 
problems being offered aren't new.  The MID was one application 
language for solving them according to some strict requirements.
One way to answer this is to actually post some requirements 
we can respond to because no matter how you do it, normative 
or non-normative, and even if the linktypes are abstract, 
you are still asking for an application language.  That was 
the punt in HyTime that was hard to accept:  that arch forms 
were not just another way to say predefined language constructs for 
inheritance.  Meta schmetta: it's a class.

> Hyperdocuments are not programs any more than relational databases are
> programs. 

Join is an operation defined universally for relational databases.
It has a predictable behavioral mapping.  For interoperation, 
(the word lightly being tossed about), it eventually required 
something like the ODBC with its levels of conformance.

You are in no position to say what hyperdocuments are.
Examples of these are abundant and most of them include 
strict definitions for operations and display types.

> Thus, issues of "API", "messaging", "functions", etc. are not
> relevant to the discussion of hyperlink *representation*. 

Nice theory.  Semantic graphs, nodes, edges, that sort of thing.
Yes, this is what I wanted from HyTime in 1989.  The confusion 
arose over whether the label on the arc meant an operation 
of some kind, and if not, how to preserve "look and feel" 
across applications.  The buttons are part of the hyperdocument.

> They are, of
> course, directly relevant to the issue of hyperlink *implementation*:
> applying behavior to links, just as they are to the issue of SGML document
> processing implementation in general.  

Yes, and by that, most people define interoperation.  So, what is being 
asked for here is not an interoperable data object, but a portable one?

> But there will be many different
> implementations for the same documents: that's the whole reason for using
> indirections like SGML in the first place.  If you focus too quickly on
> implementation details without first defining the overall data model, you
> run a serious risk of building a self-limiting system.

But you may build one that runs dependably for some time and
interoperates 
with others that aggree to the definitions of the API.  ODBC allows 
relational databases to interoperate within specified conformance 
levels.
 
> Remember: there's no difference between a hyperlink represented in an
> abstract data representation scheme and any other element type except the
> type of processing that *might* be associated with it.

Yes.  The MID team saw it that way too.  What you and Jon seem to
overlook 
is that the traversal type specification was optional.  It also had that
"other" 
thing.  It was there for people who needed the level of predictability
Terry is asking 
for (which was a strict requirement of MID), and who did not want to
program 
Scheme/LISP to get it. What you will find if you dig long enough is 
that many people require that the data structures interoperate portably, 
and that look and feel the same.  It is a very hard problem which at 
some point will forces one to include hard to pin down values like 
RGB triples, heat of the monitor using *white*, when is *white* white 
enough.   Follow the VRML list for some of that.  Hopefully, we 
don't need anything that deep, but in VRML, they do.

I think what is being said here is the answer to the question, 
do we need a set of normative relationship types.  The answer is No.
By definition, those are domain issues and you cannot satisfactorily 
define a range for your domain.  Without that, it is just CaPH again.
Now, CaPH is a good thing, but it is specific about the Conventions bit.
As I recall, the database folks made a good case that it only has 
one type:  topic.  Are you asking for that?

len

Received on Thursday, 23 January 1997 11:41:12 UTC