Re: Divide the problem

On Fri, 9 Jun 2000, David G. Durand wrote:

> The namespaces specification attributes to a namespace only the 
> property of having a string associated with it, and endorses only the 
> operation of literal comparison for determining identity of 
> namespaces.

Fine so far.

> In fact, the ability of namespaces to bear many accidental(*) 
> properties, and for schemas to do so as well, is part of the reason 
> that we need to define a language for describing namespaces and all 
> their properties, before we go trying to resolve URIs to their names.

RDF is such a language, because it can give the properties of anything
that can be named by a URI.

> To go back to a running example, if I invent a URI space labelling 
> bricks on the Brown University Campus (or even a global 
> campus-brick-location URI space), then I can't go retrieving those 
> URI's over the wire until I've defined what brick meta-data might be, 

I think this is another map/territory confusion.  When I retrieve a
document over the wire, I get a representation of the document, not
metadata about the document.  (Unless you want to say that the
document metadata includes such facts as that the first character is
"t", the next character is "h", ...)

Doing a GET on a brick: URI simply makes no sense, and there is no
reason why it should ever make sense.  Bricks are not among the objects
that the GET method ("return a representation") sensibly applies to,
any more than mailboxes or persons are.  There are other sensible
methods such as REPAINT and MORTAR (for bricks) and SUMMON and
NOTIFY (for persons) that *would* make sense, and could be accepted
by an appropriate server equipped with appropriate transducers.

> If I fail to do that, it's not well-defined what retrieval of such a 
> URI would mean: Do I fetch the brick or data about the brick? 

The former, quia impossibile.  So we see that GET is not a good
method for bricks, unless you have a pneumatic tube attached to your
computer....

> For an abstract object this ambiguity does not arise, one can _only_ 
> retrieve descriptions of the object, and thus it's even more 
> important to define the language for those descriptions. If we 
> _don't_ define such a well-known language, interoperability will be 
> impossible because the results of the retrieval will be of an 
> unpredictable data type, encoded in many posible languages.

TimBL and Dan, however, appear to deny that namespaces are abstract:
they believe that a namespace *is* its description, and if there are
multiple descriptions, that is as uncontroversial as the notion that
a text may exist in multiple formats or languages.

-- 
John Cowan                                   cowan@ccil.org
	"You need a change: try Canada"  "You need a change: try China"
		--fortune cookies opened by a couple that I know

Received on Friday, 9 June 2000 12:31:41 UTC