RE: Information resources?

-----Original Message-----
From:	www-tag-request@w3.org on behalf of ext Joshua Allen
Sent:	Fri 2004-09-10 00:20
To:	Norman Walsh; www-tag@w3.org
Cc:	
Subject:	RE: Information resources?

>... there is nothing preventing someone from minting new URIs
>that denote the actual stream of bits returned by an HTTP call.  
>
>However, I think it's very important to be consistent -- so if people
>use http: URIs to denote the "resource" rather than the
>"representation", then they should always do so -- and pick a different
>convention for denoting the representation.  

I have no problems with folks promoting particular methodologies
which help humans manage the URI space due to mnemmonic structure.
But insofar as the archtecture is concerned, URIs are opaque, and
any valid URI can be used to denote any resource. Period. Noone
should feel that they cannot or should not use an http: URI to 
denote anything they like.

Here is a concrete example of how one can use URIs to denote 
a physical object, a web page describing that physical object,
and some representations, such that all of these resources
are "web resources" (i.e. have web accessible representations):

http://example.com/someDog               physical resource (dog)
http://example.com/someDog/index         abstract resource (web page)
http://example.com/someDog/index.html    representation
http://example.com/someDog/index.txt     representation
http://example.com/someDog/index.jpg     representation

and the existing web architecture and content negotiation
machinery enables the resolution of any of the above URIs
to representations. Note that both the dog and the web page
share the same set of representations, and that each particular
representation in the example above is a representation of
three distinct resources, e.g. http://example.com/someDog/index.html
is the representation of the dog, the web page, *and* itself.

Then, folks could also define some RDF which formally described
all five of the above resources, and their nature and various
interrelationships, without any contradictions, either at the 
semantic level, or with the web machinery serving up representations 
of those resources. E.g.

http://example.com/someDog 
   rdf:type
      ex:Dog ;
   ex:hasRepresentation 
      http://example.com/someDog/index.html ;
   ex:describedBy
      http://example.com/someDog/index .

http://example.com/someDog/index
   rdf:type
      ex:WebPage ;
   ex:hasRepresentation 
      http://example.com/someDog/index.html ;
   ex:describes
      http://example.com/someDog .

http://example.com/someDog/index.html
   rdf:type
      ex:Representation .

[
   IF   { ?subject rdf:type ex:Representation }
   THEN { ?subject ex:hasRepresentation ?subject }
]

Therefore, given the above, we can infer that

http://example.com/someDog/index.html
   ex:hasRepresentation 
      http://example.com/someDog/index.html .

etc...

Furthermore, one may refer to any of these resources individually
(such as bookmarking the JPEG representation of the dog, specifically)
and thus avoid ambiguity of reference by focusing solely on the
binary stream returned from a GET request, which may be identitical
for various URIs, since those denoted resources share representations.

Simple. Clean. Coherent. Consistent. Unambiguous. Deployable today. Nice.

(and no constraints whatsoever on the nature of any resources denoted 
 by the non-URIref URIs -- no "hash voodoo" needed)

--

Let me stress, though, that the above example reflects a naming
convention, not any hard constraints on URIs, and one could just
as validly use e.g. http://example.com/someDog/index.html to
denote the dog and http://example.com/someDog to denote the PDF
encoded representation. URIs are opaque. What clarifies the nature
of the resources denoted and their relationships is the RDF at
the semantic web layer; and while mnemonic, human-meaningful
URI naming schemes are a good idea, one *cannot* at the web level,
presume anything about the resources either based on the lexical
properties of the URI or the nature of the representations
returned (but I think most folks are in pretty clear agreement
on those points).

Cheers,

Patrick

Received on Friday, 10 September 2004 06:12:20 UTC