[Prev][Next][Index][Thread]

Ontology and Epistimology for Links in XHL



OK, it's REALLY time for back to basics.  I'm getting close to a
redraft of section 1, but here's the background for the (aspiring)
rocket scientists, since I'm doing my best to write the redraft for
the web heads.

We've really got (wait for it) SIX sorts of things, types and tokens
versus notation, description and thing itself, viz:

	  notation          description      ding an sich

type       DTD fragment     linkd class       link class

instance   linkde           linkd instance    link instance


You can start at the lower left and get the sense of this.  We have
the following link description element in an XML document, say

<tm href="http://www.microsoft.com/">Windows 95</tm>

This is a instance of a type specified by the following DTD fragment
(apologies to Tim and Steve, not quite as per the existing document):

<!element tm - - (#PCDATA)>
<!attlist tm XHL CDATA #FIXED "TLINK"
             HREF CDATA #REQUIRED
             HRTYPE CDATA "URL"
             TROLE CDATA #FIXED "owner"
             SROLE CDATA #FIXED "owned">

The text is notation for a link description instance, whose internal
representation in some object language we could notate as follows:

[tlinkd
 name=tm
 source=[epd
         loc=<the A element itself>
	 name=owned]
 target=[epd
         loc=[url
	      ttype=http
	      host=xyzzy.com
	      doc='']]
         name=owner]]

That's an instance of a (subclass of) link description, with values
for various properties.  The values of the source and target
properties are themselves instances of endpoint descriptions.

This in turn, in the context of a particular application, document and
location thereof, might resolve to a link instance we could notate as
follows:

[link
 name=tm
 eps={[ep
       name=owned
       pt=*1],
      [ep
       name=owner
       pt=*2]}]

where *1 and *2 are hard pointers to groves or grove fragments or whatever.
Note that MANY different link descriptions might have given rise to
this link, whereas the relationship between link description elements
and link descriptions is much tighter.

Link description types and link types are just the appropriate
abstractions, with there being some structure to the family of link
description types (i.e. at least we have tlinkd and ilinkd with some
shared and some distinctive properties), but as far as I can see there
is only one link type, since I don't grok directionality yet.

Where is this headed?  Well, here's a translation of old terms into
new terms, easier first

   Old         New

terminus	endpoint
pointer		endpoint description
link-type	link name
pointer role    endpoint name
locator		locator
explainer	gloss
link		link or link description or link description element

All the terms 'link name', 'endpoint name', 'locator' and 'gloss' may
be used informally to apply to the constituent parts of link
descriptions and link description elements indiscriminately.

Be patient, this all IS worth it, I promise.

ht

PS.  Lest there be any confusion, I don't see this as an attempt to
start over.  I claim I'm engaged in a rational reconstruction of the
draft on the table, with virtually no change to the fundamental
content (Well, one, in that I don't see any way therein to give the
pointer role (old name) for the implicit terminus (old name).  In the
above example, the attribute 'SROLE' (source role) gives the endpoint
role for the (implicit) endpoint which is the link description element
itself, while the 'TROLE' attribute (target role) gives the endpoint
role of the endpoint explicitly described by the HRTYPE, HREF,
etc. attributes.).