Closed melanieWacker closed 9 years ago
This may not be that important, but how about copy number and barcode of the item? we recently transformed our holdings data to MODS as below.
Myung-Ja "MJ" Han Metadata Librarian 220 Main Library University of Illinois at Urbana Champaign 1408 W. Gregory Dr. (MC-522) Urbana, IL 61801 217-333-9515 (Main Library) 217-244-7809 (Grainger)
On Thu, Oct 2, 2014 at 4:01 PM, melanieWacker notifications@github.com wrote:
MODS XML allows for fairly detailed encoding of holdings information in which includes varies levels of structure. See: http://www.loc.gov/standards/mods/userguide/location.html http://www.loc.gov/standards/mods/userguide/location.html The current MODS RDF draft carries much of this over, but the structure is simplified. See: http://www.loc.gov/standards/mods/modsrdf/primer.html#location http://www.loc.gov/standards/mods/modsrdf/primer.html#aggregator
Other detailed information that can be encoded in MODS XML as attributes: 1) type attribute under physicalLocation with suggested values: current, discovery, former, creation 2) url@access with enumerated values: preview, raw object, object in context 3) url@usage with enumerated values: primary display, primary
Questions: 1) Do we agree with the current MODS/RDF approach going forward? 2) Are any of the attributes noted about worth preserving?
— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/22.
For what it’s worth, I pulled together information from a paper (unpublished) on BIBFRAME holdings. It is about a year old, so it may not be completely up to date, nor am I, and Rebecca may have updates to this.
In BIBFRAME we have the concept of HeldItem and HeldMaterial.
Properties for HeldItem:
• barcode • circulationStatus • copyNumber • copyNote • itemId • shelfMark
Subproperties of shelfMark:
• shelfMarkDdc • shelfMarkLcc • shelfMarkUdc
Properties for HeldMaterial: • accessCondition • acquisitionSource • enumerationAndChronology • heldBy • holdingFor • lendingPolicy • reproductionPolicy • retentionPolicy • subLocation
Mentioned during 10/3 call": Bibliographic holdings in Schema.org http://www.w3.org/community/schemabibex/wiki/Holdings_via_Offer
Regarding copy number and barcode (MJ's post): Since these are not elements in MODS XML, but are properties in BIBFRAME -- I think we should recommend using properties from an outside vocabulary (such as BIBFRAME) rather than defining our own.
I think that is a good approach!
Myung-Ja "MJ" Han Metadata Librarian 220 Main Library University of Illinois at Urbana Champaign 1408 W. Gregory Dr. (MC-522) Urbana, IL 61801 217-333-9515 (Main Library) 217-244-7809 (Grainger)
On Fri, Nov 7, 2014 at 9:52 AM, melanieWacker notifications@github.com wrote:
Regarding copy number and barcode (MJ's post): Since these are not elements in MODS XML, but are properties in BIBFRAME -- I think we should recommend using properties from an outside vocabulary (such as BIBFRAME) rather than defining our own.
— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/22#issuecomment-62164631.
Barcode is in BIBFRAME but copyNumber is not. (itemId is.)
From: melanieWacker [mailto:notifications@github.com] Sent: Friday, November 07, 2014 10:52 AM To: blunalucero/MODS-RDF Cc: Denenberg, Ray Subject: Re: [MODS-RDF] Location (Holdings) (#22)
Regarding copy number and barcode (MJ's post): Since these are not elements in MODS XML, but are properties in BIBFRAME -- I think we should recommend using properties from an outside vocabulary (such as BIBFRAME) rather than defining our own.
— Reply to this email directly or view it on GitHubhttps://github.com/blunalucero/MODS-RDF/issues/22#issuecomment-62164631.
I’m not so sure it’s a good idea to define the MODS RDF holding vocabulary using a mix of namespaces.
In MJ’s example:
Illustrates a use case for copyNumber and barcode, so why don't we propose these for addition to MODS?
I'm not sure what happened to copyNumber and why it was left out of the BIBFRAME vocabulary-- it may have been an oversight.
Damn github strips angle brackets and everything between.
Asterisk replaces angle brackets in my above note:
note displayLabel="Copy Number">1 /note note displayLabel="Barcode" 30112027748349 /note
Yes, I found it interesting - there is copyNote, but no cioyNumber.
Myung-Ja "MJ" Han Metadata Librarian 220 Main Library University of Illinois at Urbana Champaign 1408 W. Gregory Dr. (MC-522) Urbana, IL 61801 217-333-9515 (Main Library) 217-244-7809 (Grainger)
On Fri, Nov 7, 2014 at 10:12 AM, Rebecca Guenther notifications@github.com wrote:
I'm not sure what happened to copyNumber and why it was left out of the BIBFRAME vocabulary-- it may have been an oversight.
— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/22#issuecomment-62167959.
I give up. (I'm doing something wrong.)
In MODS when we added the holdings information, we were trying to find a simple way to express the information that isn't too granular-- i.e. a textual holdings statement. The subfield in MARC that has copy number is mapped to shelfLocator, so is part of the string. We would have to decide whether it warrants a separate subelement in MODS.
When/if we are looking to add more terms to the MODS Holdings vocabulary I think we should consult both the BIBFRAME work as well as the work that Dan Scott has done in modeling holdings using Schema.org: http://www.w3.org/community/schemabibex/wiki/Holdings_via_Offer
Here are MODS holdings that mapped to schema.org.
fyi, not all holdings record have
sc:offers
sc:Offer
On Fri, Nov 7, 2014 at 10:41 AM, Jeff Mixter notifications@github.com wrote:
When/if we are looking to add more terms to the MODS Holdings vocabulary I think we should consult both the BIBFRAME work as well as the work that Dan Scott has done in modeling holdings using Schema.org: http://www.w3.org/community/schemabibex/wiki/Holdings_via_Offer
— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/22#issuecomment-62172609.
Agreement reached during 11-07-14 working group call. See meeting notes: https://github.com/blunalucero/MODS-RDF/wiki/MODS-RDF-working-group-call-11.7.14
MODS XML allows for fairly detailed encoding of holdings information in which includes varies levels of structure. See:
http://www.loc.gov/standards/mods/userguide/location.html
http://www.loc.gov/standards/mods/userguide/location.html
The current MODS RDF draft carries much of this over, but the structure is simplified. See:
http://www.loc.gov/standards/mods/modsrdf/primer.html#location
http://www.loc.gov/standards/mods/modsrdf/primer.html#aggregator
Other detailed information that can be encoded in MODS XML as attributes: 1) type attribute under physicalLocation with suggested values: current, discovery, former, creation 2) url@access with enumerated values: preview, raw object, object in context 3) url@usage with enumerated values: primary display, primary
Questions: 1) Do we agree with the current MODS/RDF approach going forward? 2) Are any of the attributes noted about worth preserving?