You may recall my ancient post about customizing your custom post type permalinks. When I wrote that, I was still stumbling somewhat blindly through WordPress’s rewrite API. After hacking a little more with it, I think I finally understand what I’m doing enough to write a little more confidently. Continue reading “Understanding Rewrite Tags, or, Custom Permalinks for Custom Post Types in WordPress 3.0+, Part 2”
Tag: URIs
OVGTSL 2007 – Part 2 – FRAD
After lunch, Dr. Tillett moved on to the work of the FRANAR (Functional Requirements and Numbering of Authority Records) Working Group. This group recently released a draft (PDF) of FRAD (Functional Requirements for Authority Data) for public review. FRAD covers records for “Group 2 Entities”, as defined in FRBR. These entities are Persons, Corporate Bodies, and the recently added Families (this last at the request of the archival community; many librarians would rather include Families as a subset of Corporate Bodies).
After lunch, Dr. Tillett moved on to the work of the FRANAR (Functional Requirements and Numbering of Authority Records) Working Group. This group recently released a draft (PDF) of FRAD (Functional Requirements for Authority Data) for public review. FRAD covers records for “Group 2 Entities”, as defined in FRBR. These entities are Persons, Corporate Bodies, and the recently added Families (this last at the request of the archival community; many librarians would rather include Families as a subset of Corporate Bodies).
One notable development is the de-emphasis on authorized or preferred access points. Under the FRAD model, it looks like controlled access points can be developed according to different sets of rules, and one can indicate whether those rules designate an access point to be a preferred or variant form of a name. Thus, an authority record could have multiple “preferred” access points, perhaps in different scripts or languages, and it would be up to the system to select which to display to the user.
Note that the working group’s name also mentions numbering. One of their tasks was “to study the feasibility of an International Standard Authority Data Number”, basically a unique ID to be assigned by a central international body to every authority record created by any institution in the world, a URI for authority records. The working group recommended against the formation of such a body, citing costs and impracticality as the leading reasons. They did, though, recommend the use of system control numbers from maintainers of authority files (e.g., the Library of Congress, DDB) be used as identifiers.
Dereferencing URIs
It’s a topic that has come up countless times in discussions of the Semantic Web (e.g.), and it came up recently on #code4lib: should all URIs be dereferenceable, or is it worthwhile to use non-HTTP URI schemes or non-resolving HTTP URIs?
It’s a topic that has come up countless times in discussions of the Semantic Web (e.g.), and it came up recently on #code4lib: should all URIs be dereferenceable, or is it worthwhile to use non-HTTP URI schemes or non-resolving HTTP URIs?
The consensus from Semantic Web developers seems to be that URIs need not be dereferenceable, which has a certain amount of sense to it. It you give me the URI “http://jonathan.brinley.name/”, what would you put at the location “http://jonathan.brinley.name/”? If it’s a description of me, that description also has the URI “http://jonathan.brinley.name/”, giving us two resources with the same URI. With this data now in our system, we can make absurd statements like:
<http://jonathan.brinley.name/> <#describes> <http://jonathan.brinley.name/> .This is all very ambiguous, since it could be saying:
- I’m describing myself
- I’m describing the document at “http://jonathan.brinley.name/”
- The document at “http://jonathan.brinley.name/” is describing me
- The document at “http://jonathan.brinley.name/” is describing itself
Thus the GIGO principle rears its ugly head. If you give two separate resources the same URI (which is supposed to be a globally unique identifier, remember), then you should expect ambiguity to follow. If you want to identify something uniquely, and that something is not on the web, you should give it a distinct URI from something that is on the web.
So, that answered, we turn to the second half of the problem: is it worthwhile to use non-HTTP URI schemes or non-resolving HTTP URIs?
The recent discussion started with a mention of “info” URIs. These can be used to uniquely identify resources, but have the (potential) drawback of not being dereferenceable. As established above, non-dereferenceability is not inherently bad. If one simply wants to identify something uniquely, the “info” scheme will work, as will several other schemes.
But there is a certain utility in dereferenceability. As edsu asked: “if you were processing an xml file that included a particular namespace wouldn’t it be nice to get a document that describes that namespace without resorting to google?” This is a place where the HTTP scheme can still be useful, even if the resource itself isn’t available on-line. Nothing says a server has to respond to an HTTP Get request with either a 200 “OK” or a 404 “Not Found”. A 303 “See Other” is a perfectly reasonable response to a request for a particular resource, when all that can be provided is a description of that resource. The server can then point to the URI where this description does reside, which will be distinct from the URI for the resource it describes.