Re: Fragment in HTML + RDF

Tim Berners-Lee wrote:
> (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.
I prefer (3).  One reason is that when the URI is punched in a browser 
it can be automatically scrolled to where it is suppose to be instead of 
for client to search for it.

I agree there might be a mess in certain situation.  But we can solve 
the problem by developing a special mime type where a different set of 
fragment identifier semantics that interpret the fragment Id used in 
general sense.  This is what I did in the data format description 
framework (http://dfdf.inesc-id.pt, still working on it but there are 
certain material useful).  I uses an RDF representation of a data source 
to describe different data spaces, and develop a different kind of 
fragment id on the binary mime-type, that can be used in a consist way 
with what is described in RDF.

Xiaoshu

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