- From: Michael Schneider <m_schnei@gmx.de>
- Date: Wed, 08 Nov 2006 11:00:08 +0100
- To: richard@cyganiak.de
- CC: semantic-web@w3.org
Hi, again! I want to give some addition to my last post (and by this also finally answer your question "a or b?" :) ). An alternative to demanding each client to know how to handle HTML/RDF mixtures would be to take variant a): Here the job of extracting the RDF is done by the /web server/ instead of the client, after the client explicitly told him to send RDF from the given URL (by 'Accept:'). This logic, together with the RDF extraction code, could be part of the web server's implementation (perhaps as a plugin). If such a plugin becomes standard in the web server world, the editor of the web page would not have to think much about server issues. Now, using both the server side approach above and the client side approach discussed below, all possible scenarios would comfortably work, as far as I can see: Each semantic web client would either need to know how to extract RDF from a web page itself, or how to tell a web server to send the RDF from the given URL. The client side approach is more flexible, because the client has the freedom of choosing whatever information he wants to extract. And the client would also get the HTML: This is faster (network access), if HTML and RDF are both needed. On the other side, the server side approach is easier for the client to realize: It needs just a little knowledge about HTTP. Bye, Michael Michael Schneider wrote: > 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 Wednesday, 8 November 2006 10:00:20 UTC