Implement strict parsing checks

[jamesaoverton]

Based on #785 and owlcs/owlapi#988, I'd like to implement some sort of --strict option for ROBOT. This issue is for design feedback. Here's my first draft:

Regarding the unparsed triples, we can ignore them (as we currently do), warn the user, or fail. For backwards compatibility, we can't just start always failing on unparsed triples, we would need some sort of --strict flag. I think we should change from ignoring to warning, but we'd have to try it out and see how common and annoying these warnings are.

So I'm currently thinking that ioHelper should run a check after it loads an ontology: look at the OWLOntologyLoaderMetaData to see if there are any unparsedTriples, and if there are any print a loud warning to STDERR with as helpful an message as we can write.

OWLAPI also has a strict mode that we don't currently use. I'm thinking of adding a global --strict true option that would modify ioHelper in two ways:

1. enable strict mode for OWLAPI
2. throw an exception (exit non-zero) if there are unparsed triples in the OWLOntologyLoaderMetaData

We may want to add more strictness checks in the future. So maybe --strict true is all checks, but --strict can take a list of checks, such as unparsed.

[jamesaoverton]

Whatever the design choices above, I want our error messages to be as helpful as possible. The two cases I have in mind so far are:

1. RDF reification: If ROBOT sees unparsed triples with predicates rdf:subject, rdf:predicate, or rdf:object then it should warn that you're trying to use RDF reification, suggest that you could use OWL reification, and point to a longer document about this.

2. Untyped Predicates: If ROBOT sees other predicates that haven't been given OWL types (object property, annotation property, datatype property) we should suggest adding those types.

We will probably find more cases as we test this.

[cmungall]

Great tips for anyone using the OWLAPI here - I didn't know about unparsed triples!

Your suggestion makes 100% self

We already have --check for obo format. This is an orthogonal validation so probably makes sense not to overload. But we should clearly document differences.

[jamesaoverton]

@beckyjackson Does #788 completely address this, or is there still work to do?

[beckyjackson]

l believe this is resolved