RE: [VM] HTTP Cookbook, revised editor's draft

Hi all,

Some thoughts about the requirements section of the cookbook [1] ...

It has been suggested that the requirements specified are unsatisfiable and/or inappropriate [2].  

Focusing specifically on the first requirement 'M1' I tried to write out some alternatives, increasing in specificity (see below). N.B. the recipes given are currently designed to satisfy the strongest of these, i.e. M1d. 

...

M1a.

For any RDFS/OWL ontology, class, or property, 'machine-understandable' documentation for that ontology, class or property can be retrieved via the web.

M1b.

For any RDFS/OWL ontology, class or property, 'machine-understandable' documentation for that ontology, class or property can be retrieved via the web, and can be found given only the URI for that ontology, class or property.

M1c.

The 'authoritative RDF description' of an RDFS/OWL ontology, class or property denoted by an HTTP URI can be obtained by dereferencing the denoting URI.

(The 'authoritative RDF description' is returned as an HTTP response whose content type is a registered MIME type for RDF content, currently only 'application/rdf+xml'.)

M1d.

The 'authoritative RDF description' of an RDFS/OWL ontology, class or property denoted by an HTTP URI can be obtained by dereferencing the denoting URI.

(The 'authoritative RDF description' is returned as an HTTP response whose content type is a registered MIME type for RDF content, currently only 'application/rdf+xml'.)

Where the denoted resource offers some sort of content-negotation, the 'authoritative RDF description' is the default response. I.e. an HTTP GET request without an 'Accept:' header field will ultimately result in a response with content-type 'application/rdf+xml', which is a serialisation of a set of RDF statements, including those statements that constitute the 'authoritative RDF description' of the denoted resource. 



[1] http://www.w3.org/2001/sw/BestPractices/VM/http-examples/2005-11-18/#requirements

[2] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0125.html

> -----Original Message-----
> From: public-swbp-wg-request@w3.org
> [mailto:public-swbp-wg-request@w3.org]On Behalf Of Miles, AJ 
> (Alistair)
> Sent: 06 December 2005 18:46
> To: public-swbp-wg@w3.org
> Subject: RE: [VM] HTTP Cookbook, revised editor's draft
> 
> 
> 
> Hi all,
> 
> A technical note on the cookbook ...
> 
> Most of the recipes use _conditional redirects_, rather than 
> content-negotiation per se, which is normally done via a 
> type-map file, or via the MultiViews capability.
> 
> E.g. from recipe 3:
> 
> RewriteCond %{HTTP_ACCEPT} text/html [OR]
> RewriteCond %{HTTP_ACCEPT} text/xml [OR]
> RewriteCond %{HTTP_ACCEPT} application/xml [OR]
> RewriteCond %{HTTP_ACCEPT} application/xhtml+xml
> RewriteRule ^example3$ example3-content/2005-10-31.html [R=303]
> 
> RewriteRule ^example3$ example3-content/2005-10-31.rdf [R=303]
> 
> Why use conditional redirects, instead of using e.g. built in 
> content negotiation support via MultiViews?
> 
> The main reason for not using MultiViews is that it requires 
> that both the HTML and RDF files have the same file name, and 
> are located in the same directory. Although this is the case 
> for the example given in the cookbook, this is not the case 
> for other vocabs. E.g. for both SKOS and DC the HTML 
> documentation and the RDF are in completely different 
> locations. The conditional redirect setup allows the recipe 
> to be adapted to these cases where HTML and RDF content are 
> located in different directories, or possibly on different servers.
> 
> An additional reason for preferring conditional redirects is 
> that they avoid the situation where a single resource offers 
> both HTML and RDF content, and references secondary resources 
> identified via fragment identifiers. Because the semantics of 
> a secondary resource within the HTTP URI scheme are 
> determined by the content-type(s) available, there is plenty 
> of potential for ambiguous interpretation and URI collision. 
> Conditional redirects completely avoid any of this possible 
> contention, and are therefore the safest option. 
> 
> Cheers,
> 
> Al.
> 
> > -----Original Message-----
> > From: public-swbp-wg-request@w3.org
> > [mailto:public-swbp-wg-request@w3.org]On Behalf Of Miles, AJ 
> > (Alistair)
> > Sent: 28 November 2005 16:56
> > To: Thomas Baker; David Wood
> > Cc: public-swbp-wg@w3.org
> > Subject: RE: [VM] HTTP Cookbook, revised editor's draft
> > 
> > 
> > 
> > Hi Tom,
> > 
> > > I agree that we can and should recommend that people use time
> > > stamps (or version numbers) in file and directory names but
> > > suggest we take the explanation one step further.
> > > 
> > > I suggest we say somewhere that these time stamps are being
> > > used as a social convention -- not in the expectation that
> > > one should be able to extract or infer meaningful date (or
> > > version) information from a pathname or URI string.
> > 
> > I'd be happy to add this caveat also.
> > 
> > N.B. I had some more thoughts about tightly scoped bite-size 
> > chunks for VMTF work, see:
> > 
> > Change Management for RDFS/OWL Ontologies
> > Part 1. Naming
> > http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/swbp/vm/cha
> > nge-management/part1.html
> > Part 2. Metadata
> > http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/swbp/vm/cha
> > nge-management/part2.html
> > 
> > Cheers,
> > 
> > Al.
> > 
> > 
> > 
> 
>

Received on Tuesday, 6 December 2005 19:17:48 UTC