Descriptive Metadata Call 2016-05-25

Owned by Bill Branan
Jun 16, 2017
3 min read

Time: 1:00pm EDT / 10:00am PDT 

Call-In Info: Google Hangout:  https://plus.google.com/hangouts/_/g2jey2y5cjcnggkmymxziudmw4a 

New Hangout Link: https://hangouts.google.com/call/bat5imirxfdzbkeq23uze2ljzae

Moderator: carolyn.hansen (U. of Cincinnati)

Notetaker: mcmillwh (U. of Cincinnati)

Attendees: 

 

Agenda: Metadata data modeling 

  1. Review of specific usage questions; see: https://docs.google.com/spreadsheets/d/1YnunRMNS9T6j7cgsYFxqMPZoTvyGY-ZofZvdFGAykb8/edit?usp=sharing(updated to spreadsheet) 
    Note: For background on UCSD/UCSB data modeling, see notes from call: Descriptive Metadata Call 2016-03-02
    1. We previously discussed the challenges associated with pre- and post-coordinated subjects
    2. The issue of authorities for locations has been challenging for multiple institutions
      1. usually the location of a publisher is a transcribed field
        1. it was turned into a controlled field in the DPLA model
          1. available vocabularies don't support using it in this way
          2. UCSB has had to come up with work-arounds for this
          3. CHF has faced this challenge as well
            1. they are experimenting with a workflow that manually separates publisher and location
            2. hoping for a triplestore for local authorities
    3. Timelines for data model development
      1. UCSB is doing iterative development
        1. migrated into Fedora 4 Curation Concerns
        2. now that it's live, they're looking at bringing it in line with the rest of the community
        3. when doing initial data model, based it largely on what Oregon was doing and had help from DCE
      2. CHF is also doing iterative development
        1. started with Fedora 4
        2. did the modeling with help from DCE
        3. Sufia is in beta mode and people are ingesting items
          1. waiting on Sufia 7 
          2. major holdup is works
    4. Potential deliverable related to data modeling for Hydra Connect?
      1. The document at UCSD is also being used at UCSB - this could be a starting point
      2. We could highlight how local practices differ from this model
      3. The idea with the tiered model was to acknowledge that local institutions need customization, but to identify common practices
      4. The areas where institutions differ may be more helpful than commonalities
        1. the pain points doc in particular may be helpful to new implementers
  2. BIBFRAME, BIBFRAME LITE, and Hydra (improving communication, recommendations, etc)
    1. BIBFRAME Lite is an undertaking of Zepheira
    2. Can we have people using multiple predicates?
      1. MODS/RDF group is using BIBFRAME proper
    3. BIBFRAME development
      1. moves slowly and in fits and spurts
      2. can we improve communication between Hydra and LC?
        1. any way to provide recommendations?
    4. Use of multiple predicates not likely to cause issues unless Hydra community decides to tackle best practices for metadata
      1. Hydra dev very agnostic about the metadata used
    5. Who makes metadata decisions within Hydra dev?
      1. combination of Sufia devs and Hydra-in-a-Box devs
        1. whoever in those groups is collaborating on user stories
    6. Back to issue of multiple predicates in BIBFRAME Lite
      1. MODS/RDF group would like to know what's preferred in terms of properties for wider use
      2. it makes sense to coalesce on a single set of practices
      3. reasonable to rely on semantic relationships between properties using OWL/RDFS
      4. BIBFRAME Lite exists to practice applying BIBFRAME to a wider range of materials in a way that might evolve more quickly and with more agility than LC
      5. It has served standards bodies well to be cautious in development
      6. Some items in BIBFRAME 2 have been influenced by BIBFRAME Lite
      7. BIBFRAME Lite is able to work with archives in ways that BIBFRAME is currently unable to
      8. If the property needed exists in BIBFRAME, use that
        1. the BIBFRAME property will likely have more widespread support
        2. If property is not available, use the BIBFRAME Lite property
        3. Note BIBFRAME Lite properties that are equivalent to DC, schema.org, and BIBFRAME properties
          1. This muddies the waters and we need to reconsider it

          2. Schema example: http://www.bibfra.me/view/lite/dateBirth/
            http://www.bibfra.me/view/lite/subject/ => points to dcterms and bibframe

          3. title only points to dcterms, not to bibframe: http://bibfra.me/view/lite/title/
  3. Other items
    1. Next meeting in about 4 weeks
    2. Action items
      1. Think about a potential deliverable for Hydra Connect
      2. We're early in the conversation re: recommendations on BIBFRAME, so keep thinking about that
      3. When UCSD/UCSB are ready to move forward, we can look at places where BIBFRAME might be of use in their model

      4. By next meeting, MODS/RDF group will have fleshed out prototype ready, so we can review it then