- From: Ben Adida <ben@mit.edu>
- Date: Tue, 31 Jan 2006 13:02:30 -0500
- To: Jeremy Carroll <jjc@hpl.hp.com>
- Cc: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>, SWBPD list <public-swbp-wg@w3.org>, public-rdf-in-xhtml task force <public-rdf-in-xhtml-tf@w3.org>, Pat Hayes <phayes@ihmc.us>
Continuing on this point, I guess that implies the following thing: If http://example.com/foo resolves to an XHTML document, then http:// example.com/foo#bar can only be an information resource. However, if http://example.com/foo resolves to an N3 document, then http:// example.com/foo#bar *can* be an information resource, because there is no way to get a fragment of an N3 document. The first consequence is that XHTML documents are somehow second- class citizens to N3 in expressing semweb statements. That would be truly unfortunate. The second consequence is that the RDF type of a frag URI now depends on the Mime Type of the non-frag URI. That seems bad, too. -Ben On Jan 31, 2006, at 12:50 PM, Jeremy Carroll wrote: > > It is of course conceivable that we are identifying a bug with the > web architecture document rather than a bug in our use of URIs. > > The space of URIs available for non-Information resources seems to > be getting smaller and smaller, soon the Semantic Web will be > disallowed by the Web Architecture document. > > Jeremy > > Booth, David (HP Software - Boston) wrote: >>> From: Miles, AJ (Alistair) [mailto:A.J.Miles@rl.ac.uk] >>> I think that, because no element with the id attribute value "me" >>> is actually present in the document, then current specifications >>> [3,4] do not allow any conclusions about the nature of <#me> to >>> be drawn from the content-type of the document. >> I don't think that's quite correct. The WebArch makes no requirement >> that the fragment identifier actually exist in the retrieved >> document. >> The dependency is on whether a *representation* exists when the >> primary >> resource is dereferenced. From WebArch sec 3.2.1: >> [[ >> The semantics of a fragment identifier are defined by the set of >> representations that might result from a retrieval action on the >> primary >> resource. The fragment's format and resolution are therefore >> dependent >> on the type of a potentially retrieved representation, even though >> such >> a retrieval is only performed if the URI is dereferenced. If no such >> representation exists, then the semantics of the fragment are >> considered >> unknown and, effectively, unconstrained. >> ]] >> Thus, my interpretation of the WebArch is that if http:// >> example.org/foo >> returns application/xhtml+xml, then RFC3236 applies, which states: >> ". . . fragment identifiers for XHTML documents designate the >> element with the corresponding ID attribute value". If no such >> element exists, then http://example.org/foo#me identifies a >> non-existent element. The fact that no such element actually exists >> does not change the fact that that is what the URI identifies. >>> . . . >>> Please note my position given at [7]: 'I support publication of >>> this document as a Working Draft'. I do not think the publication >>> of RDF/A as Working Draft should be delayed because of this >>> particular discussion thread. >> I agree. I think the warning that Ben has added is adequate. >> David Booth >>> [3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type- >>> fragid >>> [4] http://www.ietf.org/rfc/rfc3236.txt >>> [5] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/ >>> 0152.html >>> [6] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/ >>> 0153.html >>> [7] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/ >>> 0113.html > > >
Received on Tuesday, 31 January 2006 18:02:42 UTC