 |
 |
Am I not an agent making use of a URI who is attempting to infer properties from it? Like that it represents a SuDoc, and in particular what that SuDoc is? If this kind of talmudic parsing of the TAG reccommendations to figure out what they _really_ mean is neccesary, I stand by my statement that the environment those TAG documents are encouraging is a confusing one. Jonathan Houghton,Andrew wrote: >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of >> Jonathan Rochkind >> Sent: Tuesday, April 14, 2009 10:21 AM >> To: [log in to unmask] >> Subject: Re: [CODE4LIB] resolution and identification (was Re: >> [CODE4LIB] registering info: uris?) >> >> Over in: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08- >> 17.html >> >> They suggest: "URI opacity 'Agents making use of URIs SHOULD NOT >> attempt to infer properties of the referenced resource.'" >> >> I understand why that makes sense in theory, but it's entirely >> impractical for me, as I discovered with the SuDoc experiment (which >> turned out to be a useful experiment at least in understanding my own >> requirements). If I get a URI representing (eg) a Sudoc (or an ISSN, >> or an LCCN), I need to be able to tell from the URI alone that it IS a >> Sudoc, AND I need to be able to extract the actual SuDoc identifier >> from it. That completely violates their Opacity requirement, but it's >> entirely infeasible to require me to make an individual HTTP request >> for every URI I find, to figure out what it IS. >> > > Jonathan, you need to take URI opacity in context. The document is correct > in suggesting that user agents should not attempt to infer properties of > the referenced resource. The Architecture of the Web is also clear on this > point and includes an example. Just because a resource URI ends in .html > does not mean that HTML will be the representation being returned. The > user agent is inferring a property by looking at the end of the URI to see > if it ends in .html, e.g., that the Web Document will be returning HTML. If > you really want to know for sure you need to dereference it with a HEAD > request. > > Now having said that, URI opacity applies to user agents dealing with *any* > URIs that they come across in the wild. They should not try to infer any > semantics from the URI itself. However, this doesn't mean that the minter > of a URI cannot create a policy decision for a group of URIs under their > control that contain semantics. In your example, you made a policy > decision about the URIs you were minting for SUDOCs such that the actual > SUDOC identifier would appear someplace in the URI. This is perfectly > fine and is the basis for REST URIs, but understand you created a specific > policy statement for those URIs, and if a user agent is aware of your policy > statements about the URIs you mint, then they can infer semantics from > the URIs you minted. > > Does that break URI opacity from a user agents perspective? No. It just > means that those user agents who know about your policy can infer semantics > from your URIs and those that don't should not infer any semantics because > they don't know what the policies are, e.g., you could be returning PDF > representations when the URI ends in .html, if that was your policy, and > the only way for a user agent to know that is to dereference the URI with > either HEAD or GET when they don't know what the policies are. > > > Andy. > >