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

On May 13, 2010, at 7:28 AM, Jonathan Rees wrote:

> 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.)

How is it known that U refers to B and V refers to D? This apparently  
cannot be determined by examining the GET response, But according to  
http-range-14, as I understand it (and I may well not), when the GET  
response is 200 coded, the referent *is* determined by the response.  
In this 'normal' case (bare URI without redirection), the reception of  
a 200-code forces the URI to refer to whatever it identifies. In your  
scenario, this is the same for U as for V (ignoring for the moment the  
complication over content negotiation, which is a red herring). So how  
can they differ in their referents?

>
> 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.

Sure, and they can be identified by URIs also. Swallowing the red  
herring, I would be OK with V referring to D provided that it also  
identifies D. But I don't think it is possible to identify an RDF  
graph. The generic resource B/C is not an RDF graph: it is a kind of  
quantum indeterminate state of blending between two kinds of RDF  
document.

>
> 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.

Well, Im not sure what kind of thing D is, to be honest, but I know  
that an RDF graph can't     = B or C because an RDF graph is a set,  
and B and C are definitely not sets. So I see no good reason why a  
negotiated blend of B and C should be any more similar to A than  
either of them is separately.

> 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.

OK, lets record that. :-)

>
> 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.

That usage, in  this context, is just a (IMO misleading) pun on the  
rep-word.

> This is parsimonious since it allows representation
> = REST-representation in this one case at least.

I think this parsimony is a false idol. The two senses of represent  
are so different that mixing them up is just confusing, and this  
confusion will leak into other areas.

> (Think "data
> representation", not "knowledge representation" or "parliamentary
> representation".)

Right.

>
> 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.

Why do we need this? I would have exactly the same objection to a URI  
denoting Moby Dick and returning a 200 response.  Why not keep the 200- 
coded response system strictly for referring to Webbish things (which  
can include content-negotiated generic, sure) but not other things  
(abstractions, physical things, imaginary things) which can't be  
"identified" or REST-represented. You cannot get a REST-representation  
of Moby Dick the Work. You just can't. All you can get is a REST- 
representation of some edition or form of Moby Dick. That seems to me  
to be (comparatively) clear and easy to grok. Whereas trying to push  
the 200-code boundary as far as it can be consistently pushed and  
still be squeakingly consistent with Tag Doctrine, seems to me to be  
more likely to get everyone confused.

> 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 am cool with that, but my understanding of http-range-14 is that it  
is ruled out by a 200-coded HTTP GET response. So if you want to do  
this, you have to use 303 redirection on the URI.

>
> 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.

I figured: that is my understanding of its meaning also.

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

Um... I forget. I will have to go back and check. I  think it meant  
"none of the above, exactly."

Pat

>
> Jonathan
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 13 May 2010 15:35:40 UTC