-
Notifications
You must be signed in to change notification settings - Fork 7
Validator Possibilities
Joshua Greben edited this page Apr 25, 2017
·
9 revisions
Validation should always occur as close to the thing being validated as possible. Thus, for:
-
converter code:
- test code should live in the same repository as the converter code. Includes
- unit tests for "methods" in the code
- "integration tests" for
- MARC snippets being run through the converter
- full MARC records being run through the converter.
- test code should live in the same repository as the converter code. Includes
-
RDF being manually created:
- validation during creation and/or before save in creation tool (e.g. editor)
https://github.com/ld4l-labs/marc2rdf-validator
Code base to allow validation of particulars of RDF graphs produced by various converters, starting from explicit inline MARC data in rspec test code.
Grew out of the need for some kind of code tests for the marc2bibframe 1 converter.
Ruby RSpec is used as a means of testing and validating the classes and properties of data in the produced graphs.
Has hookups for these converters, but others could be added:
- Bibframe2:
- Library of Congress marc2bibframe2 converter (https://github.com/lcnetdev/marc2bibframe2)
- LD4L-Labs Biblioteko (http://biblioteko.org/)
- Bibframe1:
- Library of Congress marc2bibframe converter (https://github.com/lcnetdev/marc2bibframe)
- what ontologies are in play?
- what versions of the ontologies?
- can we detect if graph is syntactically valid to its ontologies? where/how it is not?
- leverage existing tools, such as the 4 implementations of ShEx http://shexspec.github.io/shexTest/reports/#test-manifests
- graph visualization
- highlight particular parts
- leverage existing tools to implement this
- too far ahead of the state of converter code?
- need "objective" notion of "correct"
- specs are still a moving target?
- likely best approached by training ontology/metadata folks in how to write the tests