HQDM Extensions

[twalmsley]

HQDM is designed by the author Dr. Matthew West to be extensible in two ways - either with new types or with new data.

With new types we can extend the model using new Java classes extending existing classes, for example:

public class UkLimitedCompany extends uk.gov.gchq.magmacore.hqdm.model.Organization {
// ...
}

or by using data, e.g.:

var ukLimitedCompany = ClassServices.createKindOfOrganization(kindId);
var acmeLimited = SpatioTemporalExtentServices.creatOrganization(acmeId);
// Make acmeLimited a ukLimitedCompany
acmeLimited.addValue(HQDM.MEMBER_OF_KIND, new IRI(kindId));

MagmaCore cannot cater for all possible model extensions, so we have to provide a mechanism for extending it externally with a way of instantiating the correct Java classes from outside MagmaCore in those cases where the model is extended using types, that also works for cases where the model is extended using data.

There will also be a need for finding and using model extensions so that a community can work together to create generally useful extensions where possible.

There may also be a case for trimming out some of the lower levels of HQDM and providing them as 'standard' extensions for optional usage. E.g. not every user of MagmaCore will need the Agreement related classes, or the Money classes, so they could be excluded from programs to reduce clutter. Users can pick and choose from the available extensions applicable to their problem domain.

[twalmsley]

There are at least two options for doing this, probably more:

1. Use the SPI as described at Baeldung. This is nice because new extension providers can just be added to the classpath as needed.
2. A custom API for registering new entity factories etc.

The extensions would be available for MagmaCore to use for RDF types that it doesn't recognise, e.g. the UkLimitedCompany class described above would be handled by one of the extension providers and would appear as an integral entity type to clients that want to use it.

I'll do some initial design work and see how well this will work in practice.

[twalmsley]

I now have this working locally and will create a PR when my previous PR is merged (#156).

I created an example HQDM extension project that works with this implementation.

[twalmsley]

It has just occurred to me that this change could be enhanced create new 'kinds' on the fly it MC encounters a type that it hasn't seen before. E.g. if MC is used to read a novel HQDM data model it is likely to contain types that require HQDM extensions that aren't loaded, but perhaps MC could handle them as dynamic 'kinds'? I'll look into the possibility.

[twalmsley]

On the issue of unknown kinds (entity types) there isn't going to be enough information to create anything other than a Thing, so I will go ahead and do that.

[twalmsley]

This is now complete in the code.