Minutes, 2015-04-27

Owned by
Michael Vandermillen (Unlicensed)
Last updated: Apr 30, 2015
2 min read

I. Discussion of Mark's schematron:

  • Mark started a schematron with approx half dozen assertions covering issues he knows of where AS has requirements beyond valid ead2002.
  • We discussed  how to uncover additional requirements so that the schematron can be filled out to cover all cases.
  •  3 places to check for these requirements:

1. ruby schema file (Nathan, can you provide the specific name)

2. test json object (Nathan can provide a test object they have been using for development)

3. The user interface itself (Brad may have more pointers on this)

 

  • We discussed how the schematron could be integrated into the ArchivesSpace import stream. On Nathan's suggestion, there was a consensus that this should be developed as a separate service from the actual ead import.

- Could still be one button from the user's experience (that is, check schematron and import if successful).

- In addition, the service should be set up so that it can be run separately against multiple EAD, in prep for subsequent ingest.

- It was suggested that the schematron service might (optionally?) fix some of the issues found.

  • Brad suggested that the schematron service be generalized (perhaps after EAD schematron integration is implemented) for use with MARCXML and others (Digital Objects?)
  • As far as next steps, I (Michael) suggested that maybe we start a document on the wiki to start collaborating on collecting issues to be baked into the schematron. Mark (I think) volunteered to start the doc with his findings to date.
  • In addition to the schematron itself, we should start planning the architecture for the new service. Nathan (I think) can start an arch./workflow document to kickstart this effort.
  • Brad suggested that everyone be involved in this effort before work on any other issues. Question, how can we have everyone involved?
  • After schematron, we can focus on marcxml, then ead3.

 

II. Updates from Members

  • Updates from Duke, Harvard,NYU,  Ohio State, Yale, all in various stages of implementing AS, and doing import/export and plugin development. Michael had question about XSLT vs plugin (with whatever native ruby xml manipulation tools are available - is it nokigiri?). As Harvard is beginning a retrospective data normalization project on EAD, I'd like to continue this conversation as Harvard, AS, and other institutions work on tools for import/export.