How can consistency check results

[Petter Reinholdtsen]

After skimming through
<URL: http://edu.hioa.no/ark2100/current/syllabus/DQ%20Ouzounov.pdf >,
and reading a paper Thomas is writing on archive quality control, I
started thinking how a Noark 5 service interface implementation could
conduct various consistency checks and report back the findings to a API
user.  There is nothing about this in the current service interface
specification.

I drafted an idea in 
<URL: https://github.com/petterreinholdtsen/noark5-tester/blob/master/mangelmelding/2017-06-02-konsistenssjekk.md >,
and would like to get your feedback on this defect report.

Lets pick a simple example consistency check (the defect report have
more examples).  When creating or modifying a journalpost object in the
database, the API could check that journal date is after document date.
And probably it should conduct checks like this to ensure the metadata
in the database make sense.  But how could it report back its findings
to API users?  The change should be accepted, of course, as it might be
correct (in this case, creating the journalpost for a document that is
still being written and with a deadline in the future).  But the issue
should also be reported to the user to allow a closer look in case it
prove to be a typo instead.

I suggest a new relation is defined for consistency check results, and
this relation is returned in _links if one or more consistency checks
fail when creating or modifying an object.  Fetching the href for such
relation should return a list of all the failing checks.  Not quite sure
what the list should contain, but suspect check type, severity and
details about the detected issue should be included.

What do the rest of you think?  Is this a useful proposal to suggest as
an extention for the service interface specification?

On the server implementation side, we should make sure it is possible to
extend the server with extra consistency check modules, to allow new
checks to be tested without having to reprogram the server.  I guess it
is possible with some plugin mechanism in place, similar to how for
example the java program Minecraft allow 'mods' to change almost
anything in the game.  This would also allow students and others to
easily test out ideas on what to check in the archive.

It would probably be good if there is a global and complete list of
failing consistency checks available via the REST API (and the href
mentioned about could do a search for a specific systemID in the list to
show only the results relevant for a given object), to get a general
idea of the number of consistency check failures in the archive, split
out on check type and severity.

-- 
Happy hacking
Petter Reinholdtsen