Re: URN single or multiple variants

• Mail folder: WWW Talk Jul-Oct 1993
• Next message: Tim Berners-Lee: "Web<>Net. Re: Web presentation stuff at HCC"
• Previous message: Dale Dougherty: "InterNIC Using Interleaf"

Date: Tue, 21 Sep 93 09:50:13 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9309210750.AA04951@www3.cern.ch>
To: winograd@interval.com (Terry Winograd)
Subject: Re: URN single or multiple variants
Cc: timbl@nxoc01.cern.ch, mitra@path.net (Mitra), uri@bunyip.com,
        www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch
Status: RO

>Date: Mon, 20 Sep 1993 11:01:37 -0800
>From: winograd@interval.com (Terry Winograd)

> 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