14 return single values if owl indicates property maximum cardinality is 1

[OwenR-York]

Changes to the model loading/processing and related UI.

• RDFModels are now loaded using Jena's OntModel which adds some classes and properties to a simple RDF Model.
• Schemas URIs can be added to the model editor dialogue.
• Data models and schemas are automatically loaded using a reasoner with Jena's default OWL settings.
• Property values are now limited by schema-inferred restrictions (max cardinality)

Refactoring

• RDFPropertyProcesses.java has been added to provide some supporting state-less processing for RDFResource.getProperty().
• Code has been refactored from RDFResource.getProperty() to RDFPropertyProcesses, this reduces the complexity of the method .getProperty()

Test and examples

• OWL demo data contains a schema and model (which includes Max Cardinality)
• The original tests have been updated to account for the changes to the RDF model that occur due to Jena's OntModel representations being used to store an RDF Model. (Notably, Jena added several OWL classes/properties to a basic RDF model, which broke several tests that checked for a specific number of classes, etc.).
• Some tests have been applied using the OWL demo data and schema, these check counts of classes/properties/restrictions that should not change unless another schema or reasoner is used.
• The max cardinality limitations on properties are tested, a query for a property should return 2 values by max cardinality reduces this to 1.
• Exceeding max cardinality when querying a property value results in a System.err reporting that the returned property values have been pruned.

Future work/note

• Add more refined control for selecting Jena's Reasoner.
• Loading a data model into an OntModel adds information to a model which may not be desirable for output back to a user's data model file. When enabling editing and saving of user data models, a user's data model may need to be loaded as a plain RDFModel type. Further investigation into Jena's API around the OntModel might reveal options to write out models that commit the additional OWL and schema information.

[agarciadom]

Another minor comment: in the RDF Model configuration dialog, I'd personally put the schema URLs above the data URLs, as the schema URLs in a way are at a "higher level" than the data ones.

We can ask Dimitris and Gian what they think, though. This is just a matter of taste :-).

[agarciadom]

To avoid confusion, we should rename hasMotherboard to motherboard in the example.

[agarciadom]

Using an invalid RDF model as an example could create confusion in users, and did prompt a very interesting discussion :-D. I'd change this model to be valid (removing the extra motherboards), and I'd only introduce an invalid model as an example of how the Jena-based validation works when we work in #20. In any case, Gian commented that the Semantic Web community doesn't like to abuse OWL for validation, and instead constraint languages like SHACL would be more appropriate.

I'd also try what happens in the example Gian gave of an RDF model where Animals have legs, and we classify Animals into Monoped, Biped and Quadruped based on the number of legs they have. Try doing this:

Monoped.all.println();
Biped.all.println();
Quadruped.all.println();

for (a in Animal.all) {
  a.legs.println('Animal ' + a + ' legs: ');
}

(If you need an example of a Monoped, we could try limpets.)

This actually creates an interesting scenario, where we may be getting a single value from Monoped (since there will be a restriction that they have one leg), but in theory we'd still want a list. It does mean that while MOF2RDF-based RDF graphs would work with our idea of seeing if a restriction was imposed (in terms of producing equivalent query results), in the general case of RDF graphs you may not always want this behaviour.

If the Monoped example turns out to work in that way, we should create a backlog item to split things into two:

• A base RDFModel class without MOF2RDF awareness.
• An MOF2RDFModel subclass with added awareness of the mapping.

We would expose MOF2RDFModel as a separate "MOF2RDF Model" type, so the user would explicitly say if they want to apply the MOF2RDF encoding or not.

[agarciadom]

OK, I think it's ready to merge now. I'll do a squash merge as there has been quite a bit of experimentation which doesn't need to be in the long-term history :-).