Child pages
  • MODS and RDF Call 2016-02-08
Skip to end of metadata
Go to start of metadata

Time: 9am PDT / Noon EDT

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

Homework Reminder: 

Moderator: Steven Anderson (Boston Public Library)

Primary Notetaker:   Shawn Averkamp (etherpad link: https://etherpad.wikimedia.org/p/RDF-MODS-20160208)

Attendees:


Agenda:

  1. Introductions

  2. Conversion Code Update
    1. Steven will work on it most of Wed to start figuring out how to handle language strings in ActiveFedora. In addition, will start other elements if time allows.

  3. MODS OriginInfo Collaboration Document
    1. Remaining issues:
      1. For advanced, preference of "opaque:origination" vs "bibframe:Provider" for a wrapper element to group creation events.
        1. "bibframe:Provider" (http://bibframe.org/vocab/Provider.html) is highly stable uri and gives you a descriptive statement. But we would only support "providerRole" from the potential elements listed within it.
        2. "opaque:origination" relies on opaquenamespace (or we could have a community one for MODS predicates) that could be less reliable. But we could resolve the URI to list all the "known supported" predicates under that wrapper.
        3. Example document:  (https://docs.google.com/spreadsheets/d/1hQjkd1NUn65aagRn-4HevCGYqU77kuGglMPcAGmwIqs/edit#gid=0)
        4. Suggestions for future conversations -- discuss advantages and disadvantages of different approaches. 
        5. Limitation of bibframe approach: potential confusion, incompatibility between institutions. Pro: stability of URI
        6. Limitation of opaque or community wrapper: questionable sustainability of predicate URI. Pro: community agreement on predicates used within wrapper, easier to code for when consuming other institutions' data.
        7. Table until future discussion when more stakeholders are present?
  4. MODS Physical Description Collaboration Document
    1. Notes: 
      1. NYPL style (skos:note of <note_type>: <note text>) vs bibframe 2.0 Note Spec (https://www.loc.gov/bibframe/docs/pdf/bf2-draftspecidsnotes-10-29-2015.pdf) vs a custom note wrapper?
      2. Table until MODS Note discussion.
    2. bibframe:extent vs dcterms:extent
      1. https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;e1a74336.1602
      2. Question of whether to disobey range restrictions of dcterms:extent in favor of existing community usage. Other major organizations are already using it "incorrectly." Bibframe would be more ontologically correct. 
      3. Stephen will put the decision up to a poll over email. 
    3. Is opaque:digitalOrigin still the best option for mods:digitalOrigin?
      1. Has anyone come up with other options? DPLA does not address digitalOrigin.
      2. In the absence of any better options, we will use opaque:digitalOrigin
    4. dcterms:format for uri's to loc formats (if needed like NYPL use case). Use DCE:format for text strings of mime type?
      1. No objections to using both properties to serve both URI and literal needs.
    5. For frequency, does the predicate "dbpedia-owl:frequencyOfPublication" work as it seems like dublin core doesn't have a usable one that means the same thing (https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1601&L=DC-ARCHITECTURE&F=&S=&P=11240).
      1. Example in: https://docs.google.com/spreadsheets/d/1hQjkd1NUn65aagRn-4HevCGYqU77kuGglMPcAGmwIqs/edit?usp=sharing
      2. Does bibframe accommodate frequency? Yes, bibframe:frequency http://bibframe.org/vocab/frequency.html and range is literal.
      3. Agreed to use bibframe:frequency instead of dbpedia-owl (or dc)
  5. Abstract Individual Institution Usage And RDF Conversion
    1. BPL -- use dcterms:abstract
    2. UNC -- modsrdf:abstract, but also agrees with BPL 
    3. Amherst -- dcterms:abstract
    4. Emory -- dcterms:abstract or dcterms:description
    5. Indiana -- dcterms:abstract -- not always present
    6. NYPL -- dcterms:description to accommodate broader range of description
  6. Assignments for next time:
    1. Table of Contents
  7. Next meeting: Monday February 22nd, 12:00 PM EST

 

 

 

  • No labels