Re: [pedantic-web] Re: The OWL Ontology URI

On Thu, May 13, 2010 at 1:03 AM, Pat Hayes <phayes@ihmc.us> wrote:
> Dan, I don't think I've got my point across, and its getting lost in all
> this confusion about information resourceness. Its really a very simple
> point, and I can make it with a very simple example.  Suppose A is an RDF
> graph, and B is an RDF/XML file which encodes/is a surface syntax
> of/represents (choose your favorite terminology) that graph A. And suppose U
> is a URI which "identifies" B, in the sense that what you get back, when you
> do an HTTP GET using U, is a 'representation' (in the REST sense) of B with
> a 200 code attached. That is, the relationship between U and B is exactly
> like that between the URI of a web page, and the web page itself.

These are not the assumptions I was making. Let me try again.

A = an RDF graph
B = an RDF/XML file that encodes (etc.) A
Brep = a REST-representation of B
C = an N-triples file that encodes (etc.) A
Crep = a REST-representation of C
D = a "generic resource" (in TimBL's sense of the word, and as
permitted by the content negotiation feature of HTTP) with the
following properties:
   Brep is a REST-representation of D
   Crep is a REST-representation of D
U is a URI that is used (in RDF, say, or elsewhere) to refer to B
V is a URI that is used to refer to D

When you GET U, you get 200 + Brep. When you GET V, you might get 200
+ Brep, or you might get 200 + Crep. (Perhaps Brep / Crep is
accompanied by a Content-location: header helpfully providing a URI U
or U' referring to B or C.)

Were it not for such "generic resources" (CN), this wouldn't be a
problem. But generic resources are a central feature of web
architecture and of the reality of the web, and I think we need to
account for them somehow.

You are right that we shouldn't use U to refer to A. No argument. But
that's not the question. What we're asking is whether V can be used to
refer to A. That is, what axiom would force D != A ? I don't know of
anything in web architecture dogma that forces this.  If there is a
common understanding of the nature of D, based on the fact that it has
REST-representations, that says D cannot be an RDF graph, it's the job
of this group to record it.

The appeal of D = A is that the thing that probably unites all of the
REST-representations of D is that they are all representations
(encodings) of A. This is parsimonious since it allows representation
= REST-representation in this one case at least. (Think "data
representation", not "knowledge representation" or "parliamentary
representation".)

State introduces another complication, and perhaps that is what forces
A != D somehow.

You see, we would need a middle ground where there is a class of
resources (those we are willing to give REST-representations / 200
responses) that are "abstract enough" to be generic in the
generic-resource sense (Moby Dick, journal articles, FRBR expressions
or works, D) but not "too abstract" in the sense that the class would
include RDF graphs or strings or numbers. This seems rather tricky to
specify.

Currently I favor not specifying this class, instead providing a good
practice note explaining why you'd want A != D and laying out the
uncontroversial cases but ultimately leaving the decision up to the
"URI owner". However that approach would permit A = D, which you deny.

Or maybe you are arguing for a URI "identifying" and "denoting"
("referring to") different things?

I'm sorry I used the word "information resource". I meant it in the
sense of "something for which we'd be happy to get a 200 response" or
equivalently "something that can have REST-representations" but didn't
make this clear.

By the way, what did your 'other' answer on the poll mean?

Jonathan

Received on Thursday, 13 May 2010 12:28:36 UTC