IDRESOLVER is a simple mechanism for resolving a unique ID to a URL. The DLXS Classes can use it to, for example, link digital object identifiers in an Electronic Finding Aid to the actual digital object in another Class.
IDRESOLVER is the combination of a data table and a CGI. The table stores IDs and URLs, and the CGI responds to requests for ID resolution. It is also possible to skip the CGI and query the table directly, and some of the Classes take this approach.
The MySQL table in the DLXS database is named "idresolver". It has three fields: id, url, and modified. IDs must be unique.
The IDRESOLVER CGI ($DLXSROOT/cgi/i/idresolver/idresolver) will return a single URL (wrapped in XML) when given an ID that is in the database.
Below is an example from the Bentley Image Bank, which links from a digital image record in Image Class to the Bentley Electronic Finding Aid (in FindAid Class) using IDRESOLVER. It is also possible to link in the other direction, but this way is easier to explain and understand.
The image record has a field named "Finding Aid" containing an ID. The field is configured (in Collmgr) so that Image Class uses IDRESOLVER to turn the ID into a link. The Image Class middleware takes the value of the field, "umich-bhl-02160", passes to IDRESOLVER in the form of an HTTP request, which returns the value from the URL field in IDRESOLVER.
The above example links to the top level of the Finding Aid. Going the other direction, from the finding aid to the image record in Image Class is more specific. The list of objects in the finding aid has several links, each built by using IDRESOLVER to look up the URL by ID.
An ID may resolve to any type of URL, for instance, one that returns a result set (many items) rather than a single item. In all cases, it is up to you to create and maintain the IDs and URLs. The IDRESOLVER table and and CGI do nothing to help with this. The University of Michigan keeps a FileMaker database of IDRESOLVER IDs and URLs. Data is periodically added, removed, and updated in the FileMaker database. And then as needed, the data is dumped out of FileMaker as XML and loaded in to MySQL, replacing the existing IDRESOLVER data.
Here are the generic steps for loading or updating IDRESOLVER data.
Using the above method keeps the definition of the MySQL table in tact, including indexes.
Michigan has a more specific set of instructions for internal use that might be helpful to you in creating your own set of steps and instructions for updating idresolver.
It is worthwhile to come up with a well defined plan for creating IDs so that they are unambiguous and, in particular, unique.
For example, let's say you have a book in Text Class that has full color figures in Image Class and you want to display thumbnails for the figures in Text Class and link them to the full record and large image in Image Class. Plus, you want Image Class to link back to the page in the book. This requires 3 ID/URL pairs.
In order to disambiguate these related items, add to each ID a suffix such as "rec" for record and "th" for thumbnail. Also prefix each with a DLXS Class abbreviation and the collection id. The following is an ID for linking from Text Class to Image Class. Let's break it down because it is slightly counter-intuitive how it is constructed.
Example ID: ic-micounty-2911266.0001.001-P0000063.TIF-rec
Assume the Text Class object (i.e., XML) contains a Text Class (not Image Class) collection ID, volume ID, and page ID. And the middleware has been configured/programmed to resolve IDs for this collection in order to link to Image Class. Text Class does not, however, know the Image Class collection ID that it needs to link to. Granted, this could be hardcoded into the middleware, but it is better to leave the Image Class collection ID out of the code and let IDRESOLVER take care of it. Again, we want the above Example ID to resolve to an Image Class URL. The counter-intuitive part is that the collection id is the Text Class collection ID, but we are linking to an Image Class collection.
Keep in mind that the DLXS classes do not require IDs to follow a particular convention, but you may have to make middleware changes/overrides if you choose your own convention.
Once you have your database of IDs and URLs, you need to know how to make the Classes do look-ups.
To make Image Class look up the value of a field as an ID, use Collmgr to turn on the "idres" option in any list of display fields such as (dfltentryflds). The field value must match the ID in the IDRESOLVER table exactly. For more informatoin about enabling the idres option see Image Class COLLDB (Collection Database) Configuration.
FindAid Class is coded to look up every DAO in idresolver and build a link if it finds the ID in the IDRESOLVER table. It uses the DAO as is. The method FilterAllDaos_XML in $DLXSROOT/cgi/f/findaid/FindAidClass.pm can be overridden per collection if different behavior is needed.
Text Class attempts to resolve all FIGURE IDs. It uses IDRESOLVER if the FIGURE TYPE is INLINE or THUMBAIL. IDRESOLVER lookups assume image class. The method GenerateExternalId in $DLXSROOT/cgi/t/text/TextClass.pm can be overridden per collection if different behavior is needed.
More information about subclassing can be found in the document Subclassing in TextClass.
The utility script $DLXSROOT/bin/data2db.pl is useful for loading data in to a MySQL table and it can be subclassed for different formats.