MODS and RDF Call 2016-04-04

Time: 9am PDT / Noon EDT

Call-In Info: 712-775-7035 (Access Code: 960009)

Homework Reminder: 

Moderator: Steven Anderson (Boston Public Library)

Primary Notetaker: Eben English (etherpad link: https://etherpad.wikimedia.org/p/RDF-MODS-20160404)

Attendees:

Agenda:

  1. Introductions

  2. Conversion Code Update / Notes Testing
    1. This work is still ongoing. Currently investigating speed/performance differences between minting objects and storing strings as objects of triples. 
       
  3. Subject Element Mappings
    1. UNC-CH
      1. Explored using dcterms:subject, foaf:topic, and dcterms:temporal
      2. Minting subject objects with skos:prefLabel for value.
    2. NYPL
      1. moving away from complex (precoordinated) subjects, using FAST, but may have complex subjects from legacy data.
      2. minting local subjects (nypl:Concept), using skos:exactMatch or skos:closeMatch for URIs from vocabularies
      3. would use multiple skos:exactMatch triples for terms existing in multiple vocabs
      4. Needs to support local subjects
      5. using edm:Place (geographic subjects); edm:TimeSpan (temporal subjects)
    3. Indiana
      1. Using dcterms:subject, dcterms;temporal, dcterms:spatial
      2. Leaning away from complex subjects, but needs to do more internal research
      3. Might need to support local subjects
      4. For <mods:hierarchicalGeographic>, would likely just use TGN URI for most specific place in hierarchy
    4. BPL
      1. Using DCE:subject (Dublin Core elements), as this has a range of both strings and URIs
      2. dcterms:spatial for geographic subjects (following modeling from Hydra geo_concerns)
      3. DCE:coverage for points and bounding boxes, where values are strings conforming to DCMI Point or Box syntax
      4. For complex subjects, storing the full precoordinated string as skos:prefLabel, and component parts as rdfs:Label in a minted subject container
      5. Using skos:exactMatch, skos:closeMatch, and skos:inScheme to provide connections to existing vocabularies
    5. Amherst
      1. Still working on mapping
      2. Leaning toward complex subjects (many legacy records), not concerned with making individual component terms accessible
    6. Columbia
      1. Still working on examples
      2. Using FAST for new digital collections, but have legacy data with complex subjects
      3. possibly using bf:subject, dcterms:subject, dcterms:spatial, dcterms:temporal, but still undecided on vocabularies
    7. Emory
      1. Still working on examples, have added use cases to their mapping document

  4. Assignments for next time:
    1. Revise mappings based on today's discussion

  5. Next meeting: Monday April 4th, 9:00 AM PST (12:00 PM EST)