Re: Relationship Taxonomy Questions

W. Eliot Kimber wrote:

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

"Imagination is more important than knowledge" said Mr. Einstein;
on the other hand, eventually someone has to write code.

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

So ask.

E. Kimber - "... the interoperation of XML documents without some
general purview..."

Abstract domain?

"(eg. the Web as opposed to domain-specific purviews such as a
particular intranet.."

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.  Within a given application framework,
inter-object 
messaging is provided by the API for that framework.... err.. messages
and 
functions.  Also provided was a basic application language for defining
a 
format oriented structure which included a set of hyperlink types 
whose functional implementation was specified by the scheme (get, post,
etc.).

"... requires some basic set of link types whose meaning is well defined
and understood.."

Implementable?

"... typing links is in fact a useful thing to do for some types of
information..."

A non-abstract domain of links implementable in a system? Or abstract?

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

Hmm.  A domain without a range.:  non-implementable.  
Perhaps an abstract class is meant here which roots the tree but 
is non-instantiable except in the subclasses.

"Can these types be considered supertypes... used to define a class 
hierarchy.."

Ok.  If you want inheritance of data and methods, that sounds like a 
good idea.  Not a new one to be sure.

"Is there a preferred formalism by which the meaning of relationship 
types should be expressed ... can include a behavior specification."

Ah.  That's clear.  Sure.  On the system you propose as the domain, "The
Web" that 
is Java and a some *useless* languages like... C++.  So far, this
becomes 
MID 0.1 a la Vancouver:  how to recreate object-oriented programming
with pointy 
brackets.  We got badly beaten up for trying that by top members of the 
SGML community.  That was why we punted to an application language that 
worked, met the requirements of the customers and got the "not invented 
here" folks off our backs.

"The issue of behavior primitives is not open for discussion..."

Lots of luck on that one.  Interoperation is behavior usually achieved 
with messages and overloaded functions in OOPs.  Portability is 
file schlepping.  The joy for the programming community on the 
Web in seeing Java was they had a chance to get portability 
and interoperability.  Given the rush to extend the virtual 
machines, that may be short-lived ecstasy.  Sun says they 
can propose ways to overcome this, and we are all waiting for 
the licensing costs for that.  Business as usual.

A bit of computer science lore might help this discussion.
This lore has the virtue of having been adopted by the community that 
has to write the code.  Source:  "Fundamentals of Data Structures",
Horowitz 
and Sahni, 1977.  A bit dated but clearer than what we have now.

"Data type:  kinds of data variables may hold, e.g, integer, real,
logical, character..
language allows variables to name data of that type and provides a set
of operations 
which meaningfully manipulates these variables... there are features
which allow one 
to construct combinations of built-in types... structure... record...
however it 
is not necessary to have such a mechanism.."

"Data object:  a term referring to a set of elements say D.  For
example, the data object integers refers to D={0, +-1, ...}... D may be
finite of infinite and if D is very large, we may need to devise special
ways of representing its elements..."

The important bit:

"The notion of a data structue as distinguished from a data object is
that we want to 
describe not only the set of objects, but the way they are related. 
Saying this 
another way, we want to describe the set of operations which may legally
be 
applied to elements of the data object.  This implies we must specify
the set 
of operations and show how they work."

In short:

"A data structure is a set of domains, a designated domain, a set of
functions, 
and a set of axioms... the set of axioms describe the semantics of the
operations...
An implementation of a data structure is a mapping from d to a set of
other data 
structures e.. this mapping specifies how every object of d is to be
represented 
by the objects of e.  Secondly it requires that every function of d must
be written 
using the functions of the implementing data structures e...

The triple (DFA) is referred to as an abstract data type ... precisely
because the axioms do not imply a form of representation... the
implementation of a data structure... is the process of refining an
abstract data type until all of the operations are expressible in terms
of directly executable functions."

If y'all want this XML thing to be adopted, make sure the language is
precise.  Otherwise, we are back in Seattle with all of those blank
stares.

len

Received on Thursday, 23 January 1997 10:04:04 UTC