W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

Re: TB16 Re: Comments on arch doc draft

From: Jonathan Borden <jonathan@openhealth.org>
Date: Wed, 3 Jul 2002 08:53:12 -0400
Message-ID: <021301c22290$9b39b2c0$0a2e249b@nemc.org>
To: "Patrick Stickler" <patrick.stickler@nokia.com>, "ext Tim Bray" <tbray@textuality.com>, "WWW TAG" <www-tag@w3.org>

Patrick Stickler wrote:

> A term in some vocabulary is an abstract resource, and if the
> URI denoting that term dereferences to anything, then that is
> a bug, since it is impossible to actually obtain a representation
> of an abstract resource. Similarly, a namespace is an abstract
> resource, and thus, if a URL is used for the namespace name,
> having it resolve to anything is IMO a bug, just as for any
> abstract resource.

This argument is a wonderful example for which the phrase "begging the
question" is properly applied. Such perfectly circular examples are not seen
frequently. I applaud Patrick on the construction of this paragraph.

We give various names to representations or serializations of vocabularies
such as "schema" or "ontology" which are perfectly transportable over the
Web. Since the antecedent to your argument is clearly false**, there is no
reason to evaluate the truth of its consequence.

** a) a term in some vocabulary may or may not be either abstract or a
resource. For example if a term is identified by a URI reference, then it is
not a _resource_ in the context of the term "abstract resource" e.g. RFC
2396 (resources you recall are identified by URIs not URI references).

b) if a term in some vocabulary is identified by a URI and the URI resolves
without error, then the resource is not abstract in that sense of the term
"abstract resource".

c) the typical situation when a term is represented by a URI reference, is
that the URI resolves to a representation of the _vocabulary_ either a
schema, ontology, directory etc. and the fragment identifier is used by the
interested agent to identify the description of the desired _term_.

Received on Wednesday, 3 July 2002 08:58:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:52 UTC