Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. White paper: https://docs.google.com/document/d/1ffCyIirUkESLefBehafbacsLb_Rq7KJbTxxeoQCyLpw/edit#heading=h.7y094mt5y4wo
    1. Keeping this on the agenda as a placeholder to review periodically. 

    2. The remainder of comments refer to items still incomplete. Group is requested to remove comments they feel have been resolved already, and to make edits directly to the document.


  2. Collaboration Documents spreadsheet review and clean-up: https://docs.google.com/spreadsheets/d/1jhguUHc4ZbzhOwCvLppReepMu4pW3aNIdAkGQs4xA60/edit#gid=0 - Items listed as "Draft" or "Draft; under review":
    1. relatedItem (MODS Individual Mappings for Other Related Item Cases)
      1. One set of scenarios includes items relating back to a parent work, such as an article from a journal, chapter from a book, presentation from a proceedings, etc.
        * RDA Unconstrained namespace has a more promising predicate for relating an item back to its parent work ( http://rdaregistry.info/Elements/u/containedIn.en )
        * http://www.rdaregistry.info/Elements/u/ (may be generally useful; because it isn't strictly tied to FRBR)
        * Emory homework response is still under revision: https://docs.google.com/document/d/1eyg_jqtJUVYbaHpxjE4s2BUci0HhvwT9CP3wme-ja1I/edit#, Columbia also added a response

    2. titleInfo
      1. We will defer this until a future call when Julie can provide updates

    3. name
      1. We will defer this until a future call when Julie can provide updates
    4. subject
      1. Simon notes the group appears to have skipped Temporal Subjects - do we need to a homework assignment to complete this?
        Form of temporal value will be very different across implementations (strings vs dates). Whatever we provide will have to accept a literal
        For temporal dates, these will very often include strings as well as a date. Discussed whether or not the dates could be machine actionable, but seems like this could be overly complex
        Next steps: do homework to collect local usage and then determine needs for temporal

      2. Hierarchical geographic subjects appear to be incomplete (no RDF noted); also no mapping provided for scale and projection components. Assume we can readily find predicates for these (Biframe, others):

        1. http://id.loc.gov/ontologies/bibframe.html#p_projection

        2. http://id.loc.gov/ontologies/bibframe.html#p_scale

        3. http://www.rdaregistry.info/Elements/u/#P60565 (scale)

        4. http://www.rdaregistry.info/Elements/u/#P60542 (projection)

      3. Clarification of earlier decisions: we recommend only storing the most specific location provided (application would extrapolate broader locations from that) - e.g. as shown on line 18 or line 20 - includes coordinates

      4. Also need to clean up use of prefLabel vs rdfs:label in Column C; in cases where we're minting objects we can just keep the rdfs:label if it's identical to prefLabel

    5. identifier - under review
      1. Outstanding question: we still need a predicate for accession number 

    6. recordInfo


      1. Record creation and change dates: should we use Fedora (or preserve another system's dates?) 

      2. Can we use the original MODS rdf predicate?

      3. Need to differentiate file vs RDF object in Fedora, but some organizations also want to preserve original description dates (if metadata is pulled from another source, not always tied to Fedora activity)

      4. USDA/NAL noted some Fedora 3-specific use cases

      5. There do not appear to be predicates in MODS RDF for creation, change dates

      6. Homework: for those institutions that have these use cases, research alternate predicates for original/external record creation and change dates (distinct from Fedora activity)

  3. Next meeting: Monday 8/21 at 1 12 PM EST