W3C home > Mailing lists > Public > public-awwsw@w3.org > May 2010

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

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 11 May 2010 22:50:55 -0500
Cc: AWWSW TF <public-awwsw@w3.org>
Message-Id: <30391AAF-6B47-4C8C-B186-3C61B87A48D5@ihmc.us>
To: Jonathan Rees <jar@creativecommons.org>

On May 11, 2010, at 1:38 PM, Jonathan Rees wrote:

> On Mon, May 10, 2010 at 4:25 PM, Pat Hayes <phayes@ihmc.us> wrote:
>> Let me give an intuitive case in support of the Nays here. An RDF  
>> graph is a
>> set, which is not the same as a document, for sure. The *same*  
>> graph can be
>> encoded in a variety of different syntactic forms. Consider two  
>> documents,
>> one in RDF/XML, the other in NTriples, describing the same graph.  
>> If we
>> identify the document with the graph it describes, then these have  
>> to be the
>> same. But they aren't the same. So even if a graph is an information
>> resource (and I agree that one can make out a case for that  
>> position), it
>> certainly isn't the same information resource as any document (In  
>> RDF/XML or
>> NTriples or any other notation) that represents it syntactically.  
>> So, one
>> ought to use redirection to refer to it, according to http- 
>> range-14. So,
>> whether its an information resource or not is kind of moot, since  
>> even if it
>> is, it can't be directly identified by a URI which returns a 200  
>> code.
>>
>> Pat
>
> Suppose we have several things
>  t1. An RDF/XML document / syntactic form / representation
>  t2. An N-triples document / syntactic form / representation
>  t3. An information resource that has t1 and t2 as "representations"
>  t4. A graph that is serialized / encoded by t1 and t2
> And we have a URI U such that GET U retrieves t1 and/or t2, and such
> that U refers to t3.

Then we have already violated http-range-14. Because t1 and t2 are  
information resources themselves, and moreover they are the sources of  
the (REST-)representations that are returned with the 200-level http  
code; so, U must refer to t1 (if that is what it GETs) or to t2 (if  
*that* is what it GETs). So, it cannot refer to t3, because t3 cannot  
be identical to t1 or to t2.

> We know that:
>  - t3 has some of the same properties as t1 and t2 (e.g. authorship)
>  - t3 is not the same as t1 or t2 (differs in some properties)
>  - there are many IRs that could be t3, i.e. t3 isn't uniquely
> determined by the above (e.g. could vary according to what *other*
> representations exist, or by temporal behavior)
>
> The question is whether t4 = t3 is consistent with what has been
> decided about web architecture, and/or about "good practice" (which I
> think is what you're getting at). I don't see anything in what you say
> that would force yea or nay.

I don't think this is the primary question. The basic point is that,  
regardless of the status of t3 and t4, t1 and t2 are *definitely*  
information resources, and so are required to be the referents of any  
URI which returns 'representations' of them with a 200 code. The story  
ends there, regardless of the informational status of graphs. As long  
as graphs are not documents, and documents are information resources  
that emit representations attached to 200 http codes, we are stuck.

>
> If it's inconsistent, that is interesting because it ought to tell us
> something general about IRs, which are otherwise mysterious. (Graph is
> just a stand-in for any number of other boundary cases, such as
> journal article or referent-of-data:-URI or DOM tree or XML element or
> XML infoset.)
>
> If it's consistent, then why didn't they just do the obvious thing in
> SPARQL and say that the graph URI refers to a graph?

Because it is kind of obvious that to do that would require graphs to  
have names, and nobody was willing to admit the obvious fact that  
SPARQL fits the named-graph view so much better than it fits what the  
RDF specs say.

> That's why I
> assume the SPARQL authors determined somehow that graphs are not IRs
> (although Dan's right, they don't come out and say so and it's not
> forced).

IMO, the entire notion of 'information resource' is both (a) broken  
(in philosophy-speak, incoherent) and more important (b) completely  
unnecessary. One can state the entire content of http-range-14 without  
mentioning 'information resource'. I have done so for well over a year  
now and will continue to do so. Worrying about what TimBL (or anyone  
else) says are or are not information resources is like consulting  
squirrel entrails to find out who will win the next election.

Pat

>
> TimBL has asserted that numbers, strings, and representations are not
> information resources (despite fitting the AWWW definition perfectly,
> IMO). Perhaps graphs are like numbers and strings somehow in being
> deprived of IR-nature. It would be nice to know the details. Maybe the
> time sheet example we talked about before bears on this case: if t5
> and t6 "have" the same representations at all times, but t5 is Alan's
> time sheet and t6 is my time sheet (we coincidentally work exactly the
> same hours), they must be different resources since the have different
> "meaning" (or "intent" or "phlogiston" per earlier discussion). Maybe
> numbers, strings, representations, and graphs lack phlogiston, and
> that's why they fail the IR-nature test.
>
> No, this doesn't make sense, since RDF graphs are supposed to have  
> "meaning".
>
> Jonathan
>
>>
>> On May 10, 2010, at 10:52 AM, Jonathan Rees wrote:
>>
>>> I always have a hard time remembering whether an RDF graph is an
>>> information resource or not, but the email from Ian Davis cited by  
>>> the
>>> following message gives evidence that it normatively isn't...  Now I
>>> wonder whether the TAG and/or TimBL reviewed rdf-sparql-query and
>>> concurred with this determination; I don't remember any review,  
>>> and if
>>> there was none this borders on being a squatting issue for the term
>>> "information resource". Seems draconian to me to require separate  
>>> URIs
>>> for the document and the graph and weird to say that g in "graph  
>>> { g }
>>> ..." is not a graph. But what do I know.
>>>
>>> Jonathan
>>>
>>> ---------- Forwarded message ----------
>>> From: Ian Davis <me@iandavis.com>
>>> Date: Sat, May 8, 2010 at 5:48 AM
>>> Subject: Re: [pedantic-web] Re: The OWL Ontology URI
>>> To: pedantic-web@googlegroups.com
>>>
>>> On Fri, May 7, 2010 at 5:53 PM, Richard Cyganiak <richard@cyganiak.de 
>>> >
>>> wrote:
>>>
>>>> To put it another way: An N-Triples serialization of an RDF graph  
>>>> is a
>>>> perfect representation of that graph. The fact that you can round- 
>>>> trip
>>>> between them makes this clear. If it can have a representation,  
>>>> then it's
>>>> an
>>>> information resource and therefore it can be published as a web  
>>>> document
>>>> (with 200 status code that returns the representation).
>>>
>>> Well I argued this way 2 years ago, but it's not the consensus and
>>> it's at odds with e.g. cwm. See messages around
>>> http://lists.w3.org/Archives/Public/www-tag/2008Jan/0071.html
>>>
>>>>> Most of the schemas in your second group were authored by me, or
>>>>> by people advised by me, but I now believe they are wrong.
>>>>
>>>> Good to hear that. Any chance of getting these schemas changed,  
>>>> in the
>>>> mid-term?
>>>
>>> I'll work on it.
>>>
>>> Ian
>>>
>>>
>>
>> ------------------------------------------------------------
>> 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
>>
>>
>>
>>
>>
>>
>

------------------------------------------------------------
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 Wednesday, 12 May 2010 03:51:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC