Permissions Editing Simplified

EAD allows for an audience attribute to be set for any element within the schema. There are two options to select for the audience, internal and external, used to designate user permission to the content. By default, the lack of the audience attribute signifies that content of the element (and its descendants) is open to the public. Sometimes it is necessary for a finding aid to contain components for internal use, but are not intended to be seen by end users. Perhaps an entire series within an archival collection contains private materials--financial or membership records--but within this series are a few items which may be publicly highlighted.

EADitor now enables the editing of any of the attributes for components, including the setting of audiences.


The attribute popup pictured above is shown upon clicking the "@" link adjacent to the "Edit Component" heading at the top of the image. This link is also visible next to each EAD component under the Subcomponents tab. This popup window is an XBL component, and can very easily be applied to any element within the XForms application. The XBL file parses the EAD 2002 schema to look up the name of the element and extract all attributes and attribute groups associated with the element to dynamically populate the window (see code here).

Moreover, there is now a specific interface for editing component permissions, accessible from the administrative page (code):

Components with their audience attribute set to "internal" appear orange, while "external" ones appear green. Components that lack the audience attribute inherit the audience of their parent, which, in the case of top-level series, are visible by default.

The XSLT stylesheets to render finding aids into public XML and HTML documents were modified to put these permissions into practice. The stylesheets packaged with the EADitor general distribution will show only the unit title of an internal component if it contains an external descendant; otherwise, internal components are hidden entirely. These stylesheets can be modified fairly easily to show containers, unit dates, or other desired elements.


Ultimately, EADitor should accommodate the modification of the audience for any element in EAD--not just components as a whole--but such a feature is a delicate balancing act between usability and function. Setting the permissions at a more granular level should not interfere with the ease of the user interface. Implementation of more sophisticated access controls is ultimately dependent on user demand.

Improving Authority Control in EADitor

Having just returned Sunday from LOD-LAM and gotten pumped up on linked open data and learned about all sorts of cool stuff, I was eager Monday to get started on improving authority control in EADitor (much of which will later be applied to the Numishare general distribution). I learned of VIAF, an OCLC corporate and personal name authority service, and set off to integrate this service into EADitor's XBL components in the same way that one searches geonames for the EAD geogname element or id.loc.gov for LCSH terms for subject.



I was able to get this working in just a few short hours the other day thanks to VIAF's well-documented APIs. Like geonames, the EADitor user can still select arbitrary terms from local authority lists or input new names, but searching VIAF will go a long way toward tightening controlled access terms in EAD finding aids. Moreover, it will enable direct linking to various services from the finding aid display page itself, and those services often provide external links to other useful sites, like wikipedia or worldcat.


The links to terms listed above point the user to EADitor's search results page for that particular query. The image to the right of the term links the user to the URI for that term, hosted by the appropriate service, e.g., http://www.geonames.org/4811020/ for Kirby (W.Va.) or http://viaf.org/viaf/126085739/ for the American Numismatic Society. Also of note here is another significant change. The results from geonames are transformed into AACR2-compliant place names, with the exception of Malaysia since I have not yet been able to find a list of standard abbreviations for its territories.

I see also another use for controlled vocabulary service integration. Third parties will be able to query the EAD collection for finding aids which contain particular terms. For example, suppose that from the VIAF record for Thomas Jefferson (http://viaf.org/viaf/41866059/) one can link back to an institution's search results page for finding aids containing @authfilenumber '41866059' from @source 'viaf'.

After all, better metadata is the foundation for better information systems.

NOTE the code is available below:

http://code.google.com/p/eaditor/source/browse/trunk/xbl/eaditor/corpname/corpname.xbl
http://code.google.com/p/eaditor/source/browse/trunk/xbl/eaditor/geogname/geogname.xbl
http://code.google.com/p/eaditor/source/browse/trunk/xbl/eaditor/persname/persname.xbl