Registering the RDA Vocabularies

2,542 views

Published on

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.

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,542
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
50
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Registering the RDA Vocabularies

  1. 1. Registering the RDA Vocabularies<br />Diane I. Hillmann<br />Information Institute of Syracuse/<br />Metadata Management Associates<br />Metadata.maven@gmail.com<br />
  2. 2. Why Register?<br /><ul><li>For vocabulary users
  3. 3. Discoverability
  4. 4. Change notification
  5. 5. Potential for broader participation by the community
  6. 6. For vocabulary owners:
  7. 7. Versioning and change management
  8. 8. Notifications for users and maintainers
  9. 9. Support for vocabulary extension and community formation</li></li></ul><li>How Did We Get Involved?<br /><ul><li>In April/May 2007, the JSC met with a group including DCMI and Semantic Web experts:
  10. 10. Established the DCMI/RDA Task Group (chaired by me and Gordon Dunsire of the University of Strathclyde)
  11. 11. 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
  12. 12. The TG recruited consultants and volunteers to do the work, with funding from the British Library and Siderean Software</li></li></ul><li>The Challenges<br /><ul><li>Timing:
  13. 13. We started the registration process while the text was still in flux and the only version of the vocabularies was on a spreadsheet
  14. 14. Technology
  15. 15. The Registry had only recently implemented registration of element sets when we started on the element vocabularies
  16. 16. Standards and conventions
  17. 17. The “how-to” required to develop RDF vocabularies was still in flux</li></li></ul><li>Then, of course, there was the politics …<br />
  18. 18. Timing: The Bad News:<br /><ul><li>Most elements and vocabulary concepts were updated at least once as the vocabularies continued to develop
  19. 19. Some flip-flopped several times (“Title of Work” vs “Title of the Work” holds the record)
  20. 20. 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)
  21. 21. Final versions of the relationship vocabularies (Appendices I, J, K in the text) are still not in our hands</li></li></ul><li>Timing: The Good News<br /><ul><li>Important issues were encountered at early stages and we were able to discuss solutions with a broad swath of librarians and SemWeb experts
  22. 22. The need to create relationships between RDA to FRBR stretched our creativity and knowledge (particularly of RDF vocabulary standards)
  23. 23. We caught a lot of our own mistakes on the second and third pass
  24. 24. We gave the software a very good workout!</li></li></ul><li>Technology (Software)<br /><ul><li>Registry software has matured and stabilized as registration has proceeded
  25. 25. Status of all RDA registered elements and concepts are now “New—Proposed” but will change to “Published” prior to RDA release
  26. 26. 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</li></li></ul><li>Technology (Standards & Conventions)<br /><ul><li>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)
  27. 27. Supporting these two disparate standards has required extra care in building the vocabularies and relationships
  28. 28. We had a lot of help from the Semantic Web Community as we sought to accomplish our goals in a flexible and “correct” manner</li></li></ul><li>The General Strategy<br /><ul><li>We used the Semantic Web as our “mental model”
  29. 29. 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
  30. 30. Although IFLA had agreed in principle that the FRBR entities would be registered with an IFLA domain, that still hasn’t happened
  31. 31. Problems with the IFLA website upgrade and issues around domain choices have delayed FRBR registration
  32. 32. We registered the FRBR entities using an “example.org” domain, which we will change when an official domain is available</li></li></ul><li>Strategic Choices<br /><ul><li>In 2005, DC worked with LC to build a formal representation of the MARC Relators so that these terms could be used with DC
  33. 33. http://dublincore.org/documents/usageguide/appendix_roles.shtml
  34. 34. This work provided a template for the registration of the role terms in RDA (in Appendix I)
  35. 35. Role properties are registered at the same level as elements, rather than as attributes (as MARC does)</li></li></ul><li>URI<br />Definition<br />For use with this <br />FRBR entity<br />7/13/09<br />12<br />ALA Annual: Linked Data Program<br />
  36. 36. More specific properties<br />7/13/09<br />13<br />ALA Annual: Linked Data Program<br />
  37. 37. 7/13/09<br />14<br />ALA Annual: Linked Data Program<br />Source vocabulary<br />Specific property<br />
  38. 38. Issues and Implications<br /><ul><li>Limitations inherent in building relationships to FRBR entities as part of the element definitions are likely to come back and bite us
  39. 39. Inconsistency in techniques for relating RDA Elements and FRBR entities add to the complication of the schema
  40. 40. 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</li></li></ul><li>Relating FRBR and RDA<br /><ul><li>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
  41. 41. 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
  42. 42. It’s our view that relationships between RDA elements and FRBR entities are best made at the Description Set Profile level</li></li></ul><li>Multiple Relationships<br /><ul><li>There are multiple techniques being used in RDA to make the connection between FRBR entities and RDA elements
  43. 43. Elements related to more than one FRBR entity
  44. 44. Relationships in Appendix J actually include the name of the FRBR entity in the name and have separate definitions
  45. 45. 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)
  46. 46. In the case of “Name” it is described as specifically related to all three Group 2 entitles</li></li></ul><li>Aggregated Statements<br /><ul><li>RDA sets up Publication, Distribution, Manufacture and Production statements very much the way they have been done since catalog card days:
  47. 47. 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
  48. 48. Our concern was that such restrictions would create problems for reuse of RDA elements
  49. 49. 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)</li></li></ul><li>Adding Functionality<br /><ul><li>Feeds for additions and changes to element sets and vocabularies on available on the Registry front page
  50. 50. Discussion functionality, down to the element or concept level, will be available by fall
  51. 51. Basic Description Set Profiles are in the building phase, will be available by RDA release
  52. 52. Each Registry page now includes a Feedback link—please ask questions or tell us what you think!</li></li></ul><li>Why Is All This Important?<br /><ul><li>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
  53. 53. The RDA Elements and Vocabularies provide the basis for migrating from MARC to something that the broader information community can understand and interpret
  54. 54. Other communities are watching how we do this, and how well we meet the challenges of the future</li></li></ul><li>Thank You!<br />Check out the Registry:<br />http://metadataregistry.org<br />Contact us:<br />Metadata.maven@gmail.com<br />jonphipps@gmail.com<br />

×