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.
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
> 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.
> 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-
>>> 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
>> in suggesting that user agents should not attempt to infer properties of
>> the referenced resource. The Architecture of the Web is also clear on
>> 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
>> Now having said that, URI opacity applies to user agents dealing with
>> 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
>> 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
>> 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.