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

Moderator: Steven Anderson (Boston Public Library)

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

Attendees:

sanderson (BPL)
Eben English (BPL)
jen young (Northwestern)
Steve DiDomenico (Northwestern)
Danny Pucci (BPL)
ksgerrity (Amherst College)
soriordan (Emory University)
saverkamp (NYPL)
Sara Rubinow (NYPL)
Rebecca Fraimow (WGBH)
Robert Cole (U. of Alberta)

Agenda:

Introductions
Conversion Code Update
1. Github repo link (https://github.com/boston-library/mods2rdf) has been added to conversion project page.
2. No significant development since last meeting.
3. Other contributors welcome.
MODS OriginInfo Dates individual institution further discussion.
1. EDTF vs. edm:TimeSpan -- further discussion
  1. Appears that most date-related predicates from the dcterms namespace (created, issued, dateCopyrighted) have a range of rdf-schema#Literal, which means that using an edm:TimeSpan URI with these predicates is incorrect.
  2. Desire to avoid additional minting of date objects (which would be needed to use edm:TimeSpan) expressed by several institutions. Simplicity of EDTF is attractive.
  3. Discussion of encoded/formatted dates vs. 'free text' dates. Institutions may have many instances of both, depending on existence of legacy records and ability/resources to convert them to a new encoding such as EDTF.
    1. Possible solution: use dcterms date predicates, which accept any literal string, formatted or not. Let application decode date values during indexing/display/etc using existing Ruby libraries for parsing dates. Multiple date versions (un-encoded or encoded) can be used with the same record or in the same repository, as long as application can parse appropriately.
  4. EDTF compatibility issues?
    1. An EDTF formatted string doesn't conform to xsd:dateTime or ISO-8601 formats.
    2. Fedora doesn't really care about this, assuming that the modeling doesn't try and assert that the value is an instance of xsd:datetime.
  5. EDTF selected as recommended date format, used with dcterms:created, dcterms:issued, dcterms:dateCopyrighted
2. dateOther discussion
3. 1. Several use cases articulated – undated items, date of transcription of a previously-created resource, items that have been modified
  2. We will use dcterms:date for dateOther dates for now, this mapping is open to further research/discussion.
Next element assignment
1. Remaining elements from <originInfo>: place, publisher, edition, issuance, frequency
Next meeting: Monday December 14th, 12:00 PM EST

Browser not supported