Unit 10: Data standards

Wow do we have a lot of standards and almost need an ERM system just to keep them straight. Pesch provides some nice charts that can aid in the understanding of the standards and how they are utilized. Here is the breakdown based on the life cycle of electronic resources according to Pesch:
Acquire:
ONIX SPS
ONIX SOH
ONIX PL
ICEDIS
ERMI license terms
SERU

Access:
Z39.2 (MARC)
ONIX SOH
ICE DIS
Z39.50
MXG
Z39.91
Z39.88 (open URL)

Administer:
ERMI license terms
ONIX PL
ONIX SOH
Z39.2
TRANSFER
ONIX SRN

Support:
None

Evaluate:
COUNTER
Z39.93
SUSHI
ONIX SPS

Renew:
None, usually built-in with acquisition

So why do we need all of these standards? Well, since the way in which libraries acquire and support electronic resources is complicated, with multiple vendors and platforms, having standards should create a higher level of interoperability. Now, if we can get all of the vendors and publishers on board with standards, and perhaps actually using the same standards (I know that might be asking a lot), we could really get somewhere. However, as addressed by Carpenter of NISO, creating the standards and best practices, like SUSHI and SERU, is the easy part. Getting institutions, vendors, and publishers to use them can be challenging.
As Yue argues, and I agree, we must have at least a basic understanding of common standards and initiatives for each phase of the life cycle (selection, acquisition, administration, bibliographic/access control, and assessment), which include DLF ERMI, NISO/EDItUER (ONIX), XML-based schemas, and project COUNTER.

The DLF ERMI was established in October 2002 following a Web Hub from 2001 and resulted in a workshop on ERMS standards in May 2002. This workshop was attended by librarians, agents, and vendors, so basically all of the appropriate stakeholders. The aim of the project and workshop was to address the development of ERMS through interrelated documents defining functional requirements and data standards that could be used by the stakeholders. They came up with 47 functional requirements for ER management, charts outlining the processes associated with managing ERs through their life cycles, an ERD (ha, I know what that is!) of the relationships between entities of ERMS, and a report on how to apply XML. Overall, the final report received very positive feedback, but also provided findings for further research: consortium support and functionality, usage data, and data standards. Phase 2 (2005) will focus on data standards, license expression, and usage data. Another interesting tidbit from this article that is echoed in many of our readings is that MARC does not work well for ERs and we really should just be using XML, so I am happy to be taking that course next term.