Skip to content
flazz edited this page Sep 13, 2010 · 23 revisions

PiM

Main business logic will be declared in standard Schematron and XSLT. how to say: it’s out there in the open, declarative language

Step 1: Validation

Validation Logic

Given a PiM document via an input method, return a list of errors or none if document conforms. The main validation logic will be declared in a Schematron schema.

  1. Basic XML/Schema validation
    1. check for well-formed document, if errors then return specifics
    2. validate against XML Schema, if errors then return specifics
  2. Best Practice / METS Profile validation
    1. validate against Schematron schemas
    2. return minimally a list of errors in output methods outlined below
    3. Optional/Experimental: suggestions for each error; profile/BP citations

Input Methods

  1. given a HTTP URI of a PiM document, validate it.
  2. upload a PiM document file via a html form
  3. input a PiM document directly via a html form
  4. Web Service based
    1. via POST
    2. via GET with a URI of a PiM document passes as a query parameter.
    3. investigate what w3 validator does.

Output Formats

  1. HTML
  2. plain text
  3. XML
  4. JSON

(all but html will be directly useful to the web service, indirectly AJAX interfaces can use the rest)

Step 2: PREMIS → PiM

Given a valid PREMIS document convert it to a PiM document via the BP/METS Profile and a specified options. For the main transformation logic XSLT style sheets will be used.

Option 1: PREMIS Container

Create a METS document that has all PREMIS elements bundled together in a PREMIS container.

Option 2: METS Administrative Meta Data Containers

Create a METS document that has all PREMIS elements factored into the respective METS administrative metadata sections outlined in the BP/METS Profile.

File Section

For each PREMIS file create a METS file (in a file group inside a file section)

Structure Map

  • For each structural PREMIS representation provide the option to derive a METS structure map.
  • optionally create a flat METS structure map referencing all files
  • If no PREMIS representation is chosen create the flat structure map.

Input & Output

supported input methods are those outlined for validation above. Output will be PREMIS XML. For browser viewing a METS XMLHTML style sheet will be referenced.

Step 3: PiM → PREMIS

Given a valid PiM document destruct it according to its profile (outlined below). For the main transformation logic XSLT style sheets will be used.

Profile 1: METS Buckets

Assemble all PREMIS elements from each respective METS administrative meta data sections into a valid standalone PREMIS document (using a PREMIS container). Representation assembly below.

Profile 2: PREMIS Container

Extract the PREMIS container from the METS digiprovMD as a valid standalone PREMIS document (using a PREMIS container). Representation assembly below.

Representation Assembly

The BP recommends that METS structure maps be used for structural representations. Any preexisting PREMIS representations will be included in the compiled PREMIS document but an option will be provided to select any existing METS structure map for conversion to a PREMIS representation. HTML based interfaces will have a HTML form based option to choose the structure maps once uploaded; web service base interface will accept a query parameter denoting the ordinal position of the METS structure map in the document.

Input & Output

Supported input methods are those outlined for validation above. Output will be PREMIS XML. For browser viewing a PREMIS XMLHTML style sheet will be referenced.

Step 4: ??? File → PREMIS

Given a file (image for now) run it through JHOVE and then transform the JHOVE output to PREMIS. Priscilla

Step 5: NON PROFIT!

Development Issues

  • things that BP allows but don’t convert cleanly will either be a warning or brought before the PREMIS community.
  • pathological cases (like above) will be codified as a test fixtures to establish a determinate behavior.
  • GAP analysis & error handling
    • any conversion input must be valid (by some validation method)
      • if input is invalid a 400 class response is produced with information about why it is a bad request.
    • any conversion output must be valid (by some validation method)
      • if conversion output is invalid but input is valid then 500 class server error is produced and details saved for developers. this case is what we hope to minimize.
Clone this wiki locally