[
Lists Home |
Date Index |
Thread Index
]
On 2002-02-14 17:37, "ext Paul Prescod" <paul@prescod.net> wrote:
> Patrick Stickler wrote:
>>
>> ...
>>
>> The problem here is that if I dereference some URI expecting to
>> access that actual resource, and get some metadata or RDDL document
>> or something else in its place, how do I necessarily know that
>> that is *not* in fact the resource?
>
> You never, ever, ever get the actual resource. So it's easy to know. ;)
This is hardly a consensus view.
The issue of "what is a resource" and the relation between URIs and
resources is as clear as mud -- and the RDF Core WG has just submitted
(again ;-) a request to the TAG for this issue to recieve some
official discussion and clarification.
> I was arguing that two years ago. And I still see some virtue in it. BUT
> you are not making the argument correctly based on the Web's
> architecture. Resources are never returned.
It depends on what your definition of a resource is, and its relation
to URIs that denote it.
> An "abstract" resource is a
> resource that has no GET-able representation right now.
Or perhaps, never.
> Arguably
> choosing to make a resource abstract is a mistake because later you
> don't have the option of making it GET-able,
A mistake? Is the concept of the language "English" ever going
to be a GETable resource? Nope.
Is some term in a vocabulary ever going to be a GETable
resource? Nope.
An abstract or non-digital resource will never be GETable, so it
should never be denoted by a URI that suggests retrievability
(e.g. an 'http:' URL).
(Granted, in some distant future, when we have Star Trek technology,
some physical resource may be digitially retrievable -- beam me up,
Scotty ;-)
The fact that some resource is, by its nature, not retrievable
should be clear to an application up-front based on the URI
scheme used.
A 404 error is an *error* in retrieving a resource that is
expected to be retrievable -- not a reasonable indication of some
abstract, or non-digital non-retrievable resource.
The return of descriptive information about a non-retrievable,
abstract or non-digital resource is *wrong*, because dumb
applications (or humans ;-) may consider that to be a successful
retrieval of the resource.
It should be clear from the semantics of the URI scheme and/or
URI class if the resource is digital, and thus potentially
retrievable. Period.
With all due and sincere respect to all of the Web gods and
demigods who are my betters, the contemporary view of URI
classification is simply wrong. It may have been convenient to
simply punt, and abandon the debate out of exhaustion, but it does
not "clarify" or "resolve" the issues. Nope. Sorry.
> as some people have done
> with XML namespaces.
The (ab)use of URLs for namespaces with the expectation that they
should resolve to anything -- based on some non-standard attribution
of significance to that namespace such as denoting a vocabulary or
schema -- is a hack. It may be a clever hack, but it's a hack
nonetheless.
It's not based on any official functionality of the web architecture
defined by any W3C recommendation or any IETF RFC. It disregards
the fact that namespaces may be any kind of URI, not just http: URLs,
and disregards the fact that there is no required 1:1 mapping
between every namespace and a single vocabulary, doctype, etc.
and such (ab)use is causing no end of problems and confusion, no
matter how clever or cool some folks think it might be.
I certainly wouldn't consider that a good reason to use URLs
to denote abstract or non-digital resources! Rather, it's the
perfect example of why *not* to use URLs for abstract vocabularies,
document models, etc.
Regards,
Patrick
--
Patrick Stickler Phone: +358 50 483 9453
Senior Research Scientist Fax: +358 7180 35409
Nokia Research Center Email: patrick.stickler@nokia.com
|
