Re: Link style sheets [was REL and REV]

Dan Connolly (
Thu, 11 May 95 10:57:06 EDT

Murray Maloney writes:
> Craig Hubley writes:
> >
> > I have not yet seen one reason why REL=next is better than REL="linkas:next",
> > given that both would be hardwired into the browser,

Franklky, this "linkas:..." stuff seems whacky to me. In what way
are we defining a new URI scheme, i.e. a new way to access resources?
That seems to be a radical departure. It seems to me there's a design
that's been latent in the specs for a long time, and we're just trying
to flesh it out, not make a whole new one.

When TimBL and I discussed looking at link relationships as URIs,
the idea was to look at them as _relative_ URIs with an as-of-yet
unspecified BASE. As to how you would resolve them, why that would
be http, ftp, or your favorite information retrieval protocol.

For example, a document might look like:

<relbase href="">
<h1>My Desk</h1>

<p>My desk is in <a rel="container" href="../the-lab/">the MIT
lab for computer science</a>

A client that wanted to know about the "container" relationship would
dereference It might discover
a definition of container that says it's a transitive relation etc.
For example, the ARPA knowledge sharing effort defines several ontologies
for knowledge representation. For example, have a look at:

Mon Oct 3 23:43:01 1994

as a pretty good stab at URCs or "document metainformation."

There's a bunch more at:

And regarding CDATA vs NAMES: just be clear that there can be more
than one relationship in a link. The classic example is:
|I had imagined that figues would be reprented as
|<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
|where the relation ship values mean
| EMBED Embed this here when presenting it
| PRESENT Present this whenever the source document
| is presented
|Note that you can have various combinations of these, and if
|the browser doesn't support either one, it doesn't break.