This is very much the crux of the matter: are we defining a global
formal semantics, or just a global syntactic mechanism upon which
folks can build application-specific formal semantics?
I suggest that typed links are a form of knowledge representation.
The markup:
<base href="here.html">
<A rel="next" href="there.html">ch3</a>
can be interpreted as:
_there.html_ is _next after_ here.html
Predicate calculus is pretty expressive. You might express sentiments like:
_car.html_ is _owned by_ _fred_
or
_234234_ is a public key for _bob_
And you might write down some axioms and rules of inference for drawing
deductions from these statements. Viola! It's a formal system.
First of all, Godel's theorem says no one formal system is good enough
for all applications. Second, lots of knowledge representation stuff
says nearly the same thing.
Third, human knowledge tends not to be consistent or decidable, but
you may have applications where you want your logic to be consistent
and decidable (like security and access control systems).
So I'm very much against the idea of registration and use of these
words in the sense of a programming language. I do like Dave Raggett's
idea of having a sort of "standard library" of these relationships,
and reserving some part of the namespace for future standardization.
Then there's the question: do we want _any_ global semantics? For
example, from:
<base href="here.html">
<A rel="next" href="there.html">ch3</a>
may we deduce:
<base href="there.html">
<A rev="next" href="here.html">ch3</a>
This seems like it would be useful for back-link services and such.
Perhaps useful enough to standardize this much.
I'd prefer to replace rev by notation in the rel attribute, so
that in stead of rel="next"/rev="next", we'd have rel="next"/rel="next-inv"
or something like that.
At lunch today, TimBL suggested that rel values should be interpreted
as relative URIs with an as-yet-unspecified base. So they're
first-class objects, just like the terms they relate. We can specify
at some point in the future a way to dereference them, for example,
to download a specification of them.
This also allows you to do "higher order logic". For example, you
could say:
_docA_ is _smaller than_ _docB_
and then say:
_smaller than_ _isa_ _total order_
John Mallory's work on knowledge representation (used to answer the
whitehouse mail, e.g.) builds great big worlds of understanding around
this nucleus of binary relationships where the relationships are
first-class objects.
At the extremely theoretical end of the spectrum, I guess the lambda
calculus shows all you need is one operator and one argument:
(lambda args expr).
At a very practical end of the spectrum, the relational calculus (the
theory behind Sybase, Oracle, etc.) argues for n-ary predicates. I've
seen a sketch of an argument that says that HyTime linking boils down
to the relational calculus, so that's another argument in favor of
n-ary predicates.
To summarize:
* we don't need rel _and_ rev, though the cost of un-standardizing
REV should be considered.
* the list of values should act like a human language vocabulary,
with a somewhat organic evolution, rather than a programming
language keyword list. But: keep in mind that we may want
a URI style mechanism of dereferencing these terms.
* Don't expect the whole web to be consistent, but allow
applications that rely on consistency within some adminstrative
domain
* Make sure we at least solve the "print this tree of html documents"
problem.
* Keep an eye out for applications of typed links (and other
markup, like class and meta) to represent conventional bodies of
knowledge: schedules (gant/pert charts), org charts, USENET
threads, case law and precedents, library/journal category
hierarchies, check registers, address books, bibliographies, ...
* Leave the unsolved problems unsolved: structured argumentation
systems, proof checking, contraint-based reasoning, ...
But allow these applications to be built. Hmmm... I wonder
if these applications should be built on HTML typed links
and class/meta tags, or if they should just be new SGML document
types, or other document formats altogether. Time will tell.
Let's leave the option of doing these in HTML, if it doesn't
cost us too much.
Daniel W. Connolly "We believe in the interconnectedness of all things"
Research Technical Staff, MIT/W3C
<connolly@w3.org> http://www.w3.org/hypertext/WWW/People/Connolly