registering the rda vocabularies
DESCRIPTION
Presented at ALA Chicago at the 25th Annual meeting of the Authority Control Interest Group, July 11, 2009. Discusses the process of registering the RDA Vocabularies and some problems encountered.TRANSCRIPT
Registering the RDA
Vocabularies
Diane I. HillmannInformation Institute of
Syracuse/Metadata Management
Why Register? For vocabulary users
Discoverability Change notification Potential for broader participation by the
community
For vocabulary owners: Versioning and change management Notifications for users and maintainers Support for vocabulary extension and
community formation
How Did We Get Involved?
In April/May 2007, the JSC met with a group including DCMI and Semantic Web experts: Established the DCMI/RDA Task Group
(chaired by me and Gordon Dunsire of the University of Strathclyde)
It was agreed at the meeting that the TG would build the formal representation of the elements and vocabularies and set up an Application Profile
The TG recruited consultants and volunteers to do the work, with funding from the British Library and Siderean Software
The Challenges Timing:
We started the registration process while the text was still in flux and the only version of the vocabularies was on a spreadsheet
Technology The Registry had only recently implemented
registration of element sets when we started on the element vocabularies
Standards and conventions The “how-to” required to develop RDF
vocabularies was still in flux
Then, of course, there was the politics …
Timing: The Bad News:
Most elements and vocabulary concepts were updated at least once as the vocabularies continued to develop Some flip-flopped several times (“Title of Work” vs
“Title of the Work” holds the record)
We were often the last ones to see the revised texts, and our needs to know specifically what had changed were too often ignored (making our quality control processes far more difficult)
Final versions of the relationship vocabularies (Appendices I, J, K in the text) are still not in our hands
Timing: The Good News
Important issues were encountered at early stages and we were able to discuss solutions with a broad swath of librarians and SemWeb experts
The need to create relationships between RDA to FRBR stretched our creativity and knowledge (particularly of RDF vocabulary standards)
We caught a lot of our own mistakes on the second and third pass
We gave the software a very good workout!
Technology (Software)
Registry software has matured and stabilized as registration has proceeded
Status of all RDA registered elements and concepts are now “New—Proposed” but will change to “Published” prior to RDA release
The NSDL Registry will be announcing its new name and a new sustaining organization, “The Registry Consortium” this fall, which will bring important partners into the continued development of the software
Technology (Standards & Conventions)
A major goal was that the registered elements and concepts will be available for use in applications using either XML or RDF (we think we managed that)
Supporting these two disparate standards has required extra care in building the vocabularies and relationships
We had a lot of help from the Semantic Web Community as we sought to accomplish our goals in a flexible and “correct” manner
The General Strategy
We used the Semantic Web as our “mental model” Wanted to create a “bridge” between XML and RDF to
support innovation in the library community as a whole, not just those at the cutting edge or the trailing edge
Although IFLA had agreed in principle that the FRBR entities would be registered with an IFLA domain, that still hasn’t happened Problems with the IFLA website upgrade and issues
around domain choices have delayed FRBR registration We registered the FRBR entities using an
“example.org” domain, which we will change when an official domain is available
Strategic Choices In 2005, DC worked with LC to build a
formal representation of the MARC Relators so that these terms could be used with DC http://dublincore.org/documents/usageguide/
appendix_roles.shtml
This work provided a template for the registration of the role terms in RDA (in Appendix I) Role properties are registered at the same
level as elements, rather than as attributes (as MARC does)
URI
Definition
For use with this FRBR entity
7/13/09 12ALA Annual: Linked Data Program
More specific properties
7/13/09 13ALA Annual: Linked Data Program
7/13/09 14ALA Annual: Linked Data Program
Source vocabulary
Specific property
Issues and Implications
Limitations inherent in building relationships to FRBR entities as part of the element definitions are likely to come back and bite us
Inconsistency in techniques for relating RDA Elements and FRBR entities add to the complication of the schema
Limitations in the ability for others to re-use our data inherent in decisions made to default traditional library data element aggregation in the element definition
Relating FRBR and RDA
We had concerns with the decision to make these connections at the element level; we felt it should be done in the Description Set Profile
Because elements are specifically related to (generally) one FRBR entity, specialized communities with a different view of of their (and their user’s) needs have no alternative than to create different elements
It’s our view that relationships between RDA elements and FRBR entities are best made at the Description Set Profile level
Multiple Relationships
There are multiple techniques being used in RDA to make the connection between FRBR entities and RDA elements
Elements related to more than one FRBR entity Relationships in Appendix J actually include the name
of the FRBR entity in the name and have separate definitions
Other elements and sub-elements appear multiple times in the text and ERDs with no indication that they might be repeated elsewhere (with the same definition)
In the case of “Name” it is described as specifically related to all three Group 2 entitles
Aggregated Statements
RDA sets up Publication, Distribution, Manufacture and Production statements very much the way they have been done since catalog card days: Assumed aggregation of Place, Name and Date are
obvious leftovers from catalog cards, and are not necessary to enable indexing or display of those elements together if libraries want to do that
Our concern was that such restrictions would create problems for reuse of RDA elements This has indeed happened: we were actually told by
two SemWeb developers (one from LC) that they wanted to use “Place of Publication” but couldn’t because we had tied its use too tightly)
Adding Functionality
Feeds for additions and changes to element sets and vocabularies on available on the Registry front page
Discussion functionality, down to the element or concept level, will be available by fall
Basic Description Set Profiles are in the building phase, will be available by RDA release
Each Registry page now includes a Feedback link—please ask questions or tell us what you think!
Why Is All This Important?
Doing this work in parallel with the development of the RDA Text was an enormous challenge, but puts the library community in the position to move forward quickly
The RDA Elements and Vocabularies provide the basis for migrating from MARC to something that the broader information community can understand and interpret
Other communities are watching how we do this, and how well we meet the challenges of the future
Thank You!Check out the Registry:
http://metadataregistry.org
Contact us: