W3C home > Mailing lists > Public > www-tag@w3.org > October 2007

Re: Fragment in HTML + RDF

From: Richard Cyganiak <richard@cyganiak.de>
Date: Thu, 25 Oct 2007 12:37:30 -0400
Message-Id: <8C25B2E7-26AA-4929-9EBF-F4DD369913AE@cyganiak.de>
Cc: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "wangxiao@musc.edu" <wangxiao@musc.edu>, W3C-TAG Group WG <www-tag@w3.org>, Alan Ruttenberg <alanruttenberg@gmail.com>, Jonathan A Rees <jar@mumble.net>, Dan Connolly <connolly@w3.org>
To: Tim Berners-Lee <timbl@w3.org>

On 24 Oct 2007, at 12:01, Tim Berners-Lee wrote:
> There are three possible attitudes:
> 1) don't mix HTML and RDF, HTML will always have anchors. I think  
> that this doesn't meet the need.
> 2) Do mix RDF and HTML, allow one file to define both anchors and  
> arbitrary things.  Don't let the same fragid be used for both an  
> anchor and a thing.
> 3) Do mix them, and by the way, allow the same fragid to be used as  
> an ID for an anchor and an ID for a thing, with RDF clients and  
> HTML clienst doing different things.  I think that this path leads  
> to madness, as in a script for exaple, I may want to use a URI to  
> refer to one or the other unambiguously. It also makes it  
> impossible for HTML+RDF clients.
> So (2) is my preference, and I feel it should be written down  
> somewhere. Actually the MIME type registration for HTML would be  
> the logical place.  A TAG finding could be  pragmatic place too.

I agree that it's an important issue. I agree that 2) would be a huge  
improvement over 1), and that 3) is a recipe for disaster.

Regarding Xiaoshu's point that 2) doesn't allow us to click on an RDF  
hash URI and end up scrolled to the right spot in the HTML: I agree  
that this is a problem. But I think it's a Web browser implementation  
issue, and can be worked around with in-browser trickery, such as a  
bit of Javascript. So I'd say there's no need to bend the architecture.


> Tim BL
Received on Thursday, 25 October 2007 16:37:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:18 UTC