Fragment in HTML + RDF

(Was: Resources and representations (was RE: Subgroup to handle  
semantics of HTTP etc?))

I'm forking this as it is a specific point the community has to  
address: can we mix RDF fragids and HTML fragids in the same file?

On 2007-10 -24, at 11:29, Booth, David (HP Software - Boston) wrote:
> [...] - If the URI denotes a non-information resource and the URI  
> has a fragment identifier and a 200 response is returned when the  
> racine (the part before the '#') of the URI is dereferenced, then  
> the media type returned must be a media type that permits its  
> fragment identifiers to denote arbitrary resources.   For example,  
> you may return RDF but *not* (currently) HTML, because the media  
> type for RDF permits a fragment identifier to denote anything,  
> whereas in HTML a fragment identifier denotes a location within the  
> document.

In general, this is right. So for example if we put a lot of python  
on the web, I would expect the things after the fragment identifiers  
to be file-globals like class names, function names and file-level  
variables.  That is the constraint of python.  Just as a constraint  
of HTML   *was* that it could only express anchors as end-points  
(hence 'anchor').

But now in XML of course we can mix namespaces, and anyway people are  
talking about maybe putting RDFa into the HTML namespace itself. So  
now, it seems XML and HTML both are languages where you can't make  
any conclusions about what  sort of an internal thing is defined.

I think the general rule holds, but for HTML we need to revise it,  
with RDFa. etc.

Also, GRDDL

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.

Tim BL

Received on Wednesday, 24 October 2007 16:02:07 UTC