Re: secondary resources

Booth, David (HP Software - Boston) wrote:

>>    Reading the RDF/XML representation returned, we learn that
>> http://norman.walsh.name/knows/who#norman-walsh
>>    is a Male Person:
>>
>> [[
>> <rdf:Description 
>> rdf:about="http://norman.walsh.name/knows/who#norman-walsh">
>>        <rdf:type
> rdf:resource="http://nwalsh.com/rdf/contacts#Contact"/>
>>        <rdf:type rdf:resource="http://nwalsh.com/rdf/genealogy#Male"/>
>>        <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
>> ]]
> 
> Okay.  I only received text/html (XHTML 1.0 Transitional) from
> http://norman.walsh.name/knows/who when I just tried it, but I'm
> assuming it also sends RDF/XML if it gets the right Accept headers.

I cheated, I asked for http://norman.walsh.name/knows/who.rdf, I'll see 
if I can get Jena to get that file with the URL 
http://norman.walsh.name/knows/who
and report back.

> Well, the norman.walsh.name server has asserted that #norman-walsh is
> both a person and a location within a document:
> 
> 	<http://norman.walsh.name/knows/who#norman-walsh> 
> 		a tag:Location-Within-An-HTML-Document ,
> 		a <http://xmlns.com/foaf/0.1/Person> .
> 
> I don't know if this is a contradiction -- it would be if foaf:Person is
> owl:disjointWith tag:Location-Within-An-HTML-Document -- but it does not
> seem to be using the foaf: ontology the way foaf: was intended.  The
> foaf: ontology clearly distinguishes between a foaf:Person and a
> foaf:Document, and even provides a foaf:PersonalProfileDocument property
> that explicitly relates the two.  The above seems to conflate them.
> 
> Perhaps the notion of "punning" that Pat Hayes mentioned would
> rationalize this -- I'm afraid I have not understood it well enough yet
> -- but it looks to me like Norm has unwittingly dirtied his data by
> permitting his server to (implicitly) assert that #norman-walsh is a
> tag:Location-Within-An-HTML-Document .

I think the point of Pat's argument, which I am trying to illustrate, is 
that this is a natural, normal, working behaviour, fully compatible with 
interoperability, and actually provides additional interoperability 
between the Web and Semantic Web rather than an unwitting bug.

> 
> The WebArch sec 3.2.2  on "Fragment identifiers and content negotiation"
> says that the use of "content negotiation to serve representation
> formats that have inconsistent fragment identifier semantics" is a
> "server management error" that "leads to URI collision".[1]  However,
> WebArch sec 3.2.2 also says that "The representation provider decides
> when definitions of fragment identifier semantics are are sufficiently
> consistent.".  

So, in those terms, the discussion is about what is "sufficiently 
consistent" - it seems to me that directing a browser client to a 
paragraph that provides (in English) the same description of the URI as 
the RDF/XML provides in a machine readable form, does provide 
sufficiently consistent behaviour, and then we need to define 
'semantics' in such a way that interoperable behaviour reflects 
consistent semantics.


> It sounds like you are giving preference to one assertion (that
> #norman-walsh is a foaf:Person) over the other (that #norman-walsh is a
> tag:Location-Within-An-HTML-Document).  That makes me uneasy.  


Yes I am.
The mime type for RDF/XML is about documents that contain such 
assertions. If I find such an assertion in a document with that mime 
type at the URL in question, then I take that as the intent.

The mime type for HTML is about display/presentation of information to 
humans. If I find some HTML fragment at that URL then that is one that I 
  would want to display to a human, to convey the information.

The HTML mime type does not make assertions, it tells you about 
presenting information. The RDF/XML mime type does not tell you about 
display, it tells you about assertions.

We can scrape some assertions off from an HTML document, but that is an 
error prone process. In particular, I think this thread indicates that a 
general rule that <a name="norman-walsh"> in an HTML document can be 
scraped as:
#norman-walsh is a tag:Location-Within-An-HTML-Document
is overly eager and leads to false positives. (i.e. asserts triples that 
are false)

> As I explained in [3], I don't think the failure to define the fragment
> identifier within the HTML document changes the meaning of a URI that
> uses that fragment identifier.  In HTML, it just means that
> http://www.w3.org/People/Connolly/#me (when served as HTML) identifies a
> non-existent location within the document.  
> 

I tend to agree. I find Tim's page the only one that is wholly 
consistent with the interpretation of WebArch that you have been giving. 
Tim's page though then reflects this breach between Web and SemWeb.

Jeremy

Received on Thursday, 2 February 2006 11:17:24 UTC