MODS and RDF Call 2015-11-16
Time: 9am PDT / Noon EDT
Call-In Info: 712-775-7035 (Access Code: 960009)
Homework Reminder:
Individual Mappings of OriginInfo Dates: MODS OriginInfo Dates Individual Institution Usage And RDF Conversion
- Test out the MODS XML to RDF code at: http://mods2rdf.xyz/uploads
Moderator: Steven Anderson (Boston Public Library)
Primary Notetaker: Juliet Hardesty (etherpad link: https://etherpad.wikimedia.org/p/RDF-MODS-20151116)
Attendees:
-
-
- Juliet Hardesty (Indiana University)
-
Danny Pucci (BPL)
- Kelcy Shepherd (Amherst College)
- ksgerrity (Amherst College)
-
soriordan (Emory University)
- saverkamp (NYPL)
- Sara Rubinow (NYPL)
Agenda:
- Conversion code update
- Username and password is on site now and also in notes from last meeting.
- Steven DiDomenico updated Fedora and is deploying Solr on Northwestern-hosted site.
- Continuing to develop instance and add features, where should announcements go? Github readme, elsewhere?
- use Github readme and add link to Fedora example site.
- MODS Genre Items
- NYPL example use case (https://docs.google.com/document/d/11XyFEyLN8_LZp1Yb2Y-qlgD-kogqmeEIC6gOItmj32s/edit?usp=sharing)
- for local genre resolution.
- NYPL is minting local terms so would be consistent way of identifying those.
- Can go from SKOS concept to scheme or number of schemes so might have different types of schemes in use (broader/narrower terms).
- Might not really affect recommendation for MODS to RDF.
- NYPL approach connected more to larger scale RDF vocabulary management beyond Fedora and digital object mgmt
- Have to dereference and cache those terms somewhere anyway, so easier to store those locally and index from that so there doesn't have to be terms indexed separately as terms we manage and terms managed somewhere else
- Means that Fedora records have to be updated with remote sources labels.
- How is this different from text being stored in Solr and using a caching sidecar (ie. could use Marmotta-style triple store that would handle dereferencing URIs)?
- Means that Fedora records have to be updated with remote sources labels.
- Not something we would use as part of our recommendation but good use case to have as example for folks with similar situation
- Collaboration Document: https://goo.gl/jX2NOy
- marcgt is not linked data list; map these 50 terms to AAT?
- Marcgt in genre form terms? http://id.loc.gov/vocabulary/genreFormSchemes.html ?
- Just the schemas for possible genre vocabularies are located there... individual term definitions are not.
- What are advantages to using AAT for these terms? might not all map from marcgt to aat
- Doesn't need to all be AAT... just a consistent mapping to some equivalent vocabulary term.
- Just that marcgt is fairly common so could be helpful to have those mapped to Linked Data but can leave that as text string?
- In the end, decision was to not include any default marcgt conversion mapping. Would just become string literal values... conversion to a linked data source would have to be run by the individual institution first.
- Marcgt in genre form terms? http://id.loc.gov/vocabulary/genreFormSchemes.html ?
- marcgt is not linked data list; map these 50 terms to AAT?
- NYPL example use case (https://docs.google.com/document/d/11XyFEyLN8_LZp1Yb2Y-qlgD-kogqmeEIC6gOItmj32s/edit?usp=sharing)
- MODS OriginInfo Dates individual institution mappings.
- Amherst
- Didn't accommodate attributes as much; how to accommodate keyDates? for date ranges, have to have app logic to decide which date is keyDate - probably first date but app decides this.
- BPL has application logic as to what dates they consider most important if multiple date types exist (ie. dateCreated over dateIssued and such).
- Didn't accommodate attributes as much; how to accommodate keyDates? for date ranges, have to have app logic to decide which date is keyDate - probably first date but app decides this.
- BPL
- EDTF standard in draft from LOC; date range can have open end date, can have unknown for beginning date. Essentially all of the date logic is encoded into that string format.
- Using dcterms for mapping and syntax from EDTF.
- No inferred concept in EDTF but there is approximate using tilda (~); add a note (maybe in SKOS) saying date was supplied by cataloger.
- Is it important to have a way to note that date is inferred or not?
- If info is available, it’s helpful, but not used often.
- Amherst and BPL already have those notes when it was inferred - but for others, generate automatically or just have translation include approximate notation and not include note?
- Drop inferred, make it approximate, make date questionable.
- Archival materials are often undated so wouldn't want to recommend supplying a note.
- Amherst would map each occurence (approx and questionable).
- Maybe it is better to drop any ~ or ? and allow notes to clarify (if they are supplied).
- This last option is what was decided.
- EDTF standard in draft from LOC; date range can have open end date, can have unknown for beginning date. Essentially all of the date logic is encoded into that string format.
- Amherst