- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Mon, 19 Dec 2005 18:19:29 -0500
- To: <public-swbp-wg@w3.org>
- Cc: "Miles, AJ \\(Alistair\\" <A.J.Miles@rl.ac.uk>, "David Wood" <dwood@softwarememetics.com>, <swick@w3.org>
At last, here is my review of "Configuring Apache HTTP Server for RDFS/OWL Ontologies Cookbook" http://www.w3.org/2001/sw/BestPractices/VM/http-examples/2005-11-18/ Sorry for the delay in finishing it. This is a very helpful document, and will be good to publish. Thank you for preparing it! GLOBAL SUGGESTIONS: G1. It would be good to add information (or a link to information) on the trade-offs between hash and slash URIs, since that is the first decision someone will need to make. G2. Regarding the sentence: [[ Note also that PURL servers use a 302 redirect code, and therefore ontologies with slash namespaces using PURL servers will not strictly conform with the TAG resolution on httpRange-14 [@@TODOREF]. ]] I think it would be best to avoid giving advice that violates the TAG's httpRange-14 decision[5], and as I note below, I think some of the recipes currently violate the TAG's decision. COMMENTS ON SPECIFIC RECIPES Recipe 1. Hash Configuration, Minimal. This recipe uses hash URIs, no redirection, and always returns RDF. This looks fine. Recipe 2. Slash Configuration, Minimal. This recipe uses slash URIs with 303-redirect and always returns RDF. This looks fine. Recipe 3. Hash Configuration, Extended. This recipe uses hash URIs with 303-redirect and returns either HTML or RDF. I believe this recipe conforms to the TAG's httpRange-14 decision[5], but because the interpretation of a fragment identifier in the presence of 303 redirects is unclear as far as I know[4], I think this recipe should note that the browser may or may not apply the fragment identifier to the secondary URI. Recipe 4. Slash Configuration, Extended, Single HTML Document. This recipe uses slash URIs with 303-redirect and returns either HTML (with a secondary fragment identifier) or RDF, depending on the content type requested. This looks fine. Recipe 5. Slash Configuration, Extended, Multiple HTML Documents. This recipe uses slash URIs with 303-redirect and returns either HTML or RDF, depending on the content type requested. RDF is returned from a single document, but when HTML is returned, the tail of the path is mapped to an individual HTML document. This looks fine. Recipe 6. PURL Hash Configuration, Minimal. Hash URI with purl.org (302) redirect to RDF content. If purl.org is modified to do 303 redirects instead of 302, I think this recipe would be fine. (But we should note that the browser may or may not apply the fragment identifier to the secondary URI.) However, since purl.org currently uses 302 redirects, and the implications of that are currently unclear[4], I do not think we should recommend this recipe as a best practice at this time. Recipe 7. PURL Slash Configuration, Minimal. Slash URI with purl.org (302) redirect to RDF content. I think this recipe maps the tail of the original URI (i.e., the class or property names) to individual documents on the secondary server. If purl.org is modified to do 303 redirects instead of 302, I think this recipe would be fine. However, since purl.org currently uses 302 redirects, and the implications of that are currently unclear[4], I do not think we should recommend this recipe as a best practice at this time. Recipe 8. PURL Hash Configuration, Extended. Hash URI with purl.org (302) redirect to a secondary URI, which in turn does a 303-redirect to a tertiary URI to serve either RDF or HTML, depending on the content type requested. If purl.org is modified to do 303 redirects instead of 302, I think this recipe would be fine. (But we should note that the browser may or may not apply the fragment identifier to the tertiary URI.) However, since purl.org currently uses 302 redirects, and the implications of that are currently unclear[4], I do not think we should recommend this recipe as a best practice at this time. This issue is NOT mitigated by the fact that the secondary URI does a 303-redirect to a tertiary URI, because the issue is caused by the initial 302 redirect. EDITORIAL SUGGESTIONS E1. Shorter URIs in the examples would be better. For example, http://isegserv.itd.rl.ac.uk/VM/http-examples/example4/classA is rather long, and hence the relevant aspects are harder to see. Perhaps also use http://example.com instead of http://www.example.com , for brevity. E2. At the beginning of each recipe, say what the URIs would return. For example, in recipe 4 you might say something like: [[ http://isegserv.itd.rl.ac.uk/VM/http-examples/example4/classA is 303-redirected to http://isegserv.itd.rl.ac.uk/VM/http-examples/example4-content/2005-10-3 1.html#classA or to http://isegserv.itd.rl.ac.uk/VM/http-examples/example4-content/2005-10-3 1.rdf depending on the content type requested. ]] REFERENCES 1. RDF Concepts section on Fragment Identifiers: http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-fragID 2. David Booth's proposed URI minting strategy: http://www.w3.org/2002/02/mid/A5EEF5A4F0F0FD4DBA33093A0B07559008911A37@t ayexc18.americas.cpqcorp.net;list=public-swbp-wg 3. David Booth's 12 Dec message on minting URIs: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0056.html 4. David Booth's 19 Dec message on 302 versus 303: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0123.html 5. TAG's httpRange-14 decision: http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html David Booth, Ph.D. HP Software dbooth@hp.com Phone: +1 617 629 8881
Received on Monday, 19 December 2005 23:20:00 UTC