 |
 |
The "User Agent" is understood to be a typical browser, or other piece of software, like wget, curl, etc. It's the thing implementing the client side of the specs. I don't think "you" are operating as a user agent here as much as you are a server application. That is, assuming I have any idea what you're actually doing. --Joe On Tue, Apr 14, 2009 at 11:27 AM, Jonathan Rochkind <[log in to unmask]>wrote: > 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. >> >> >> >