Re: [Fwd: xmlns, uri+name pairs or just uris..? Clarification needed.]

I pretty much agree with all Dan says here.

I have found it useful to use the idea of a resource being a "conceptual 
mapping" (language from RFC 2396, I think), without any directly visible 
content of its own.  I think it could be useful to have some formalization 
of a resource that captures the ideas mentioned here.

I am concerned that there does not seem to be consensus about the 
relationship between URIs and resources:  some say URI:resource is 1:1, 
some say it's N:1.  I think either can work depending on the exact 
definition of the underlying idea of "resource".

#g
--

At 10:56 AM 8/11/00 +0100, Dan Brickley wrote:
>On Fri, 11 Aug 2000, Pierre-Antoine CHAMPIN wrote:
>
> > "McBride, Brian" wrote:
> > > In that case I would be troubled about what the URI Ref that
> > > names a property actually names.  Does it name the property
> > > or does it name the document/document fragment that describes
> > > the property.  The foundation of the web is that URI's denote
> > > one resource;
> >
> > That is exactly the point, IMO :
> > the document/document fragment describing a property is *not* the 
> property, and they should not be mandated to have the same URI (though I 
> admit this is a very practical way of naming properties...)
>
>This used to bother me a lot, until I came to a more abstract view of
>what something like http://www.w3.org/Icons/w3c_main is a name for.
>Or something like http://example.com/xmlns-evocab/v1.
>
>It's a 'thing known to the Web' that can expose different renderings of
>itself according to contextual circumstance. Eg. if I send it a 'GET'
>HTTP message today, with a certain bundles of
>content-negotiation preferences, authentication information etc., it'll
>respond with a mime-typed bunch of bytes that presents one view of
>itself. You never get the actual Web thing itself, only
>views/renderings of it. Conceptually, the Web thing
>http://www.w3.org/Icons/w3c_main isn't
>intrinsically a PNG, GIF, JPEG or SVG, but can render these views of
>itself when asked.
>
>I believe the same point holds for Web data vocabularies, whether
>they're XML, RDF, PICS or P3P data schemas. They have a name on the Web,
>and typically (dereferencing being a privilege not a right...) they'll
>present useful views of themselves in response to HTTP 'GET' messages.
>
>The Namespace URI then names the property in the abstract, but when we
>send a 'GET' to the Web service that knows authoritatively about that
>URI, we'll get back a (possibly content-negotiated) document that
>presents some view of the abstract resource. Just like doing a GET to
>the Web service that knows authoritatively about some 'visual image'
>resource.
>
>
>So, having come to this view, I'm now only a bit bothered by
>the apparent wierdness. Semantics of '#' still concern me though (in
>general, not just for RDF).
>
>Dan
>
>
>ps. the old HTTP-NG work describes this issues quite nicely:
>http://www.w3.org/TR/WD-HTTP-NG-interfaces/
>
>When we think of the Web today, the idea of a 'resource' comes to
>mind. In general, a resource is an Object that has
>some methods (e.g. in HTTP, Get Head and Post) that can be invoked on
>it. Objects may be stateful in that they
>have some sort of opaque 'native data' that influences their
>behavior. The nature of this native data is unknown to
>the outside, unless the object explicitly makes it known somehow. [Any
>stateful object may or may not have some
>means by which it stores persistent state across activations, but that's
>not really part of our concern here.]

------------
Graham Klyne
(GK@ACM.ORG)

Received on Thursday, 24 August 2000 09:09:30 UTC