Re: Namespaces wihtout "#" Was: Few CWM Bugs

[...]
> I *suppose* one could just have "/" as another option,
> but the optimum would be, I assumed, to search for the
> longest match.

Well, if you have a prefix dictionary anyway, then that should take
some of the sting out of the matching. I know that it's a problem; I
used to just hack the last character off of a URI and use the rest as
a namespace in XML RDF output to save me the trouble.

[...]
> The second issue is more significant.   In my worldview,
> (which I claim to be (a) consistent and (b) useful)
> http://example.org/x is a document.  You can't reuse
> its URI for an abstract thing without a change to HTTP.

O.K., then we just change HTTP. What we're all quibbling over are
those few words in the HTTP spec.:-

[[[
10.2.1 200 OK [...]
   GET    an entity corresponding to the requested resource is sent in
          the response;
]]] - RFC 2616, 10.2.1

Roy has argued strongly that an entity corresponding to the resource
is a representation of the resource. You are saying that the
correspondance pertains to the resource as a document. "200 OK" is
certainly an acceptable return code (IMO) whether you find some
information that *represents* what you're looking for, or whether the
information *is* what you're looking for, so all we need to do is add
some more information to the header to disambiguate.

So, here goes with a new field name:-

   EntityType = "Entity-Type" ":" ( "Resource" | "Representation" )

If the header is added, then there can be no argument. If the header
is not present, then we simply do not define what is meant. I'm sure
that this will satisfy both points of view: for the
representationalists (Roy, Aaron, DanBri) a response of "Entity-Type:
Resource" means that the representation that is returned is also the
resource being requested.

It would satify me too, because I've always argued that people use the
two different levels interchangably without giving the holder of the
resource a chance to define it. Well, now you can. We've not really
needed to define before, because we didn't build formal KRep systems
on top of it, or if we did, then we just generally agreed what the
things meant.

So... call for objections? Comments?

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Sunday, 25 November 2001 10:46:35 UTC