Agenda:

Conversion Code Update
1. No conversion code updates to report. Work will commence soon.
series, subseries, collection, institution Individual Institution Usage And RDF Conversion discussion
1. Only BPL and Columbia completed the mapping. BPL is primarily looking at using BIBFRAME, bf:seriesStatement, bf:subseriesStatement, bf:seriesOf, bf:subseriesOf and bf:partOf (the latter is used for the physical archival collection). Opaque namespace is used to facilitate going several subseries deep. Section 19 shows a more complete example of how the subseries is minted into the system. BPL is applying pcdm to express relationships within the system (e.g. pcdm:isMemberOf for systems sets (digital collections) pcdm:isMemberOf is proposed, but not yet officially in pcdm.
  
  Dicsussion: bf:seriesOf and seriesStatement may apply to published series rather than archival series. Definition of seriesStatement: “usually transcribed; includes the ISSN if applicable.” seems to indicate that this property has its origin in the MARC 490. BPL will look into this.
  
  Columbia is suggesting dcterms:isPartOf to link to archival collections. Columbia coins identifiers for archival collections and has plans to provide descriptions in RDF. Suggests possibility to use Archiveshub ontology to express series and subseries (http://data.archiveshub.ac.uk/id/level/fonds and http://data.archiveshub.ac.uk/id/level/subfonds) However, this requires managing objects for every series and subseries which is a lot of overhead and not practical. Perfect scenario would be for the finding aids to be available in rdf so that it would be possible to link directly to the desired level. Use of RDA unconstrained property rdau:P60193 (in series) instead of BIBFRAME for commercial series since RDA unconstrained properties are not linked to WEMI or other data model.
  
  This agenda item will be discussed again on the next call when more institutions are represented.
Decision on remaining issues voting results
1. https://docs.google.com/spreadsheets/d/1myLYmUoOX5i1FKBjDat39ZR8cEZ644lATNj6juCQ5xA/edit?usp=sharing
2. Extent: Two votes for modsrdf;physicalExtent – one for opaque:extent, one for VRA RDF. Decision to go ahead using modsrdf (no objection on the call)
  Title: One vote for bf:Title, 4 to retain the current mapping. Decision to go ahead and retain the current mapping.
  
  Accession no: http://id.loc.gov/vocabulary/identifiers/local was suggested. Agreement that organizations interested in retaining the concept of an accession no. would want that specificity. Decision to move forward with opaque:accessionNumber
part, extension, and recordInfo collaboration document review
1. https://docs.google.com/spreadsheets/d/103__DdqlTPMXFsANLtEhQpRUbphnL3oeQoOcPygF2GU/edit?usp=sharing
2. recordInfo: Up to the individual institutions which elements they want to retain in an RDF environment. No objections – continued next time when more institutions are on the call. MODS recordCreationDate and recordChangeDate only recorded in the examples provided by two institutions. Do we need it? Columbia is currently leaning towards maintaining that information using MODS RDF (recordInfoRecordCreationDate and recordInfoRecordChangeDate)
  Part: Only used by Indiana. The example of the usage is very institution specific. Will be brought up next time when a representative of Indiana is on the call.
  Extension: Each institution is using the extension differently. Not mapped. Up to individual institution.
Other Collaboration Document discussion
1. None
Next meeting: Monday November 14th at 9:00 AM PST / Noon EST

Browser not supported