- From: Michael Schneider <m_schnei@gmx.de>
- Date: Tue, 07 Nov 2006 23:49:23 +0100
- To: richard@cyganiak.de
- CC: semantic-web@w3.org
Hi, Richard! Here is, what I believe. My consideration does not fully answer your question ("a or b?"), but perhaps it is a little help to you. I try to think of meaningful use cases, where one wants to have both an HTML file and RDF data with the same base URI, and the only relevant use case I can see for now is, to have the HTML file as the primary object (some web page), with the RDF data closely related to this web page. E.g. in your example, it would probably be some personal homepage (that of John) together with some metadata and a machine readable version of the web page's content. Now, AFAIK, there are actually two ways to associate RDF data with a web page: Either by building a "<link rel='alternate'>" to an external RDF file, or by embedding the RDF into the (X)HTML (microformats, or RDFa in some near future) of the web page. Note, that it is even possible, to combine these two techniques, and the RDF data would then be the sum of both parts. If this was the situation, than I believe that there is no need for special handling on the server side (neither a) nor b)). Just place the web page at that URL ("http://.../john"), and let the client do the whole job: * If the URI was inspected by some traditional web browser, all it does is loading the web page (HTML), jumping to the given anchor (".../john#me") and render the page from this position on. * If the URI was inspected by some kind of semantic web browser, it would /also/ just load the HTML of the web page, then extract the RDF (the client will of course know how to extract embedded RDF or follow the <link>), and finally fetch the RDF resource specified by URI "..../john#me". Bye, Michael Richard Cyganiak wrote: > Hi all, > > One good practice for identifying non-document resources is to use > "hash URIs" like http://example/john#me, and to serve a description > at the URI obtained by taking the part before the hash, e.g. http:// > example/john. > > Now let's say I want to serve both RDF and HTML descriptions of John. > That is, both formats should be available from http://example.org/ > john, depending on the request's Accept: header. How to do this? > > a) Just return the requested type of content right at http:// > example.org/john > > b) Redirect to two different URLs, depending on the requested type, > e.g. http://example.org/john.html and http://example.org/john.rdf > > I notice that the SWBP Vocabulary Recipes [1] suggest b). I have a > hunch that a) is problematic because it's a bit ambiguous, http:// > example.org/john#me could refer either to John, or to an anchor > within an HTML page, if there's no 303 redirect in between. So, is > only b) allowed, or is a) fine too? > > Comments? > > Cheers, > Richard > > [1] http://www.w3.org/TR/swbp-vocab-pub/#recipe3
Received on Tuesday, 7 November 2006 22:50:00 UTC