W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > February 2006

Re: [ALL] RDF/A Primer Version

From: Steven Pemberton <steven.pemberton@cwi.nl>
Date: Wed, 01 Feb 2006 13:16:46 +0100
Message-ID: <43E0A6AE.2080802@cwi.nl>
To: Ben Adida <ben@mit.edu>
Cc: Jeremy Carroll <jjc@hpl.hp.com>, "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>

Ben Adida wrote:
> 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.

Following on from what I believe Mark was saying at the last call, 
http://example.com/foo may resolve to both an XHTML document *and* an N3 
document (and many other things) depending on the accept: headers, so 
http://example.com/foo#bar could represent (many) different things.

Steven

> 
> -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 Wednesday, 1 February 2006 12:17:04 UTC

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