> For example,
> there could be a URN for "the text content of the declaration of
> independence" and another one for "The US Govt. standard SGML
declaration
>of independence" and yet another for "Andy Warhol's postscript
rendering
>of..." There would be formats for describing the relations between
these
>so that for operations requiring a particular kind of invariance, a
person
>(or program) could find the appropriate information.
I agree. In WWW, the link type is the place for this
information. The WWW worskshop decided to define
a WWW-Link: message field for expressing these
relationships in HTTP for any object, semantically
equivalent the <LINK> tag in an HTML document, with
parameters including relationship and URI of other object.
>This requires that each "information object" be given a
characterization by
>a "responsible party" as to what variance it is intended to cover.
Yes. I saw the responsible party as being the URL
issuer.
>That
>is, each of the above three examples in addition to having a unique
>identifying string would have auxiliary information saying what
constitutes
>its "unique identity".
In the current HTTP spec,
Live-URI: xxxxx
means that the URI given may return different objects
under the "update" transformation, and
Message-ID: xxxxx
means that xxxxx is guaranteed to always dereference
to the same version.
The language and data format are specified in other
fields ("Content-type" and "Language:") and one
can in the request insist on a particular format
or the original (Accept: "www/source").
How could we generalize this futher? Suppose for
each type of variation we define (as we dicover them)
fields such as
Content-type:
Language:
Version:
And then we merge Live-URI and Message-ID to make one
URI: field with a parameter which lists the prperties
which are invariant. Or variant. Like
URI: xxxxx; fixed = language, content-type, version
or
URI: yyyyy; vary=content-type
What do you think?
Is this sufficiently flexible?
What should the default be?
I am inclined to think that the safest is that the default
is absolute identity, and that all variations must be
specified. This allows weird new transformations to be
included, and old clients to at least know that something
fishy is going on when they see
URI: zzzzz; vary=psychomorph
>I am saying that it is up to the creator of an information object
for which
>there will be a URN to specify just what constitutes a "variant"
(meaining
>an instance of the same URN), with a vocabulary of choices to select
from.
Is the above what you intended?
>I might create a URN for a paper I am writing and have all of the
versions
>be variants, and I might in addition create a URN for today's
version, with
>an appropriate link saying it is a version of the paper.
Precisely.
> Future versions
>would have new URNs of the second kind but still be linked to the
same one
>of the first kind.
Exactly.
> Choice as to when to do this would be up to the
>creator, not legislated by the protocol.
Certainly. Though we must define the "vocabulary"
>This makes the basic structure more complicated but in the end
should
>provide principled grounds for dealing with the huge tangle of
real-world
>complications that we are looking at.
Absolutely.
> It can be extended in a natural way
>to include relationships of derived information (e.g., summaries,
indices,
>etc.) and of annotation (responses, comments, glosses, edited
versions (in
>the sense of Shakespeare books), etc.)
Yes. Here is an example of an object's meta information:
URI: xxxxx
URI: yyyyy vary = interpretation, langage, version, edition
WWW-Link: rel=describes; href=zzzzz
WWW-Link: rev=summarises; href=qqqqq
The xxxxx refers to this particular bitstream. yyyyy
refers to the works of Shakespeare in general, included
illustrated annotated copies published by other
people. This document describes the 17th century world,
identified by topic zzzzz. There is a summary of the works
of shakespeare identifiued by qqqqq.
You have to access qqqqq to find out what sort of a mutable
beast qqqqq referss to.
What do you think, wizards? Make HTTP take Terry's very good
points into account in this way?
>--t[erry]
--tim