Take control of your SAP testing with UiPath Test Suite
A Consideration of Library Holdings in the World Beyond MARC
1. A Consideration of Library Holdings
in the World Beyond MARC
ALCTS/CRS Holdings Information
Committee, 2014 ALA
Midwinter, Philadelphia
2. Why Holdings?
• Is there still a need for the functionality the
standards were designed for?
• How do we balance needs for complexity
(detail) with perceived value of simplicity
(summary)?
• Who’s working on this and what are they
doing?
• Can we predict the future of holdings?
3. Functionality
• Traditional functional needs
– Communication between libraries and
vendors/publishers about subscriptions, payments
and issuances
– Communication between libraries about specific
availability for access (including ILL)
– Management of materials internally (e.g., predictive
checkin, remote storage, preservation, etc.
– Support for users with specific (and sometimes
problematic) citations
4. Holdings Standards in the Analog
World
• MARC 21 Holdings:
http://loc.gov/marc/holdings/echdhome.html
• NISO Z39.71
http://www.niso.org/standards/z39-71-2006/
• ISO 10324:1997 (available for purchase from
ISO)
5. List of Ongoing Efforts
• https://wiki.dnb.de/display/DINIAGKIM/Collec
tion+of+Holdings+Ontologies%2C+Vocabularie
s%2C+Standards
– Compliments of the DNB (German National
Library)
6. Ongoing Efforts: DNB
• https://wiki.dnb.de/display/DINIAGKIM/Scope
+of+Holdings
– Work in progress, further information on their wiki
7.
8. Ongoing Efforts: ONIX
• ONIX for Serials Coverage Statement - Version
1.0 (Published March 2012)
http://www.editeur.org/123/Serials-CoverageStatement/
• Used primarily for messaging between
publishers, vendors, and libraries
• Based to some extent on MFHD
9.
10. Ongoing Efforts: schema.org
• Schema.org “provides a collection of schemas,
i.e., html tags, that webmasters can use to
markup their pages in ways recognized by
major search providers. Search engines
including Bing, Google, Yahoo! and Yanex rely
on this markup to improve the display of
search results, making it easier to find the
right web pages.”
11. Current Proposal for Library Holdings in schema.org
Proposed property
Comment
Library = seller
Will be treated be schema.org processors as the
organization or individual offering the item; the
fact that it may be a loan instead of a sale can
be handled as part of the Offer.
Call #/Shelf # = sku
As an inventory identifier and physical locator
for a specific organization [sku] is a reasonable
match for a call number
Barcode = serial
number
A unique identifier for a single item,
serialNumber is a good match for barcodes
Shelving location =
availableAtOrFrom
In practice most sites will likely supply a simple
text value like "Stacks" or "Reference"
Item status =
availability
Using terms from schema.org and Good
Relations (mostly sale oriented)
http://www.w3.org/community/schemabibex/wiki/Holdings_via_Offer
12. Ongoing Efforts: MMA
• Work based on MARC 21 Bib format:
http://marc21rdf.info
– Goal: Enabling use of MARC holdings for mapping
or re-use in a different environment
– Using cataloger-readable URIs:
http://marc21rdf.info/elements/3XX/M300__a
13.
14.
15. Is There One Answer?
• Not likely, we’re no longer living in a ‘one-sizefits-all’ world
• The functional requirements vary greatly based
on needs of particular communities
– As digital materials and technology proliferate
further, this gap may increase
• Holdings approaches change as their ‘parent’
schemas do
– Decisions on schema usage generally not made on
basis of holdings needs
These are library standards, not generally used by publishers. MARC / Z39.17 dichotomy parallel to MARC/AACR2 and RDA Vocabularies/RDA Toolkit
List provided by DNB research—not all are of general interest.
Further discussion on the DNB website seems to indicate a basis of Z39.71 for the data itself
The ONIX for Serials Coverage Statement was strongly influenced by the content and rules found in the MFHD. However, there are several differences.The ONIX coverage structure is a component of the family of ONIX XML messages, so consistency with the existing ONIX structure was a primary concern.The ONIX coverage statement also has a more specific list of functional requirements than MFHD, so a substantial portion of the MFHD functionality was omitted from the ONIX design.Also, because ONIX coverage statements should be machine actionable, the use of freetext fields to express significant data is not permitted, although freetext notes to offer additional clarifications are encouraged.ONIX coverage is most closely analogous to the Enumeration and Chronology fields (863-865) of MFHD.An ONIX coverage statement may be re-expressed in MFHD without loss of information, but not all MFHD statements can be expressed completely within an ONIX coverage statement.Specifically, the ONIX for Serials coverage statement:Does not support publication pattern informationDoesnot support copy-level information for physical pieces, such as barcodes, copy number, or “lost” or “withdrawn” designations.Does not support free text enumeration and chronology statements