Add SHACL constraints

[kentthang010]

Builds upon @DrJonasWestman's initial SHACL file by adding constraints that were present in FederationDescriptionReader.java and feddesc.ttl but not in feddesc.shacl.ttl. Also changes the shape definitions to only accept xsd:anyURI literals.

May not cover all constraints present in FederationDescriptionReader.java or feddesc.ttl.

Ignores BoltInterface, GraphQLEndpointInterface and MappingConfiguration constraints for now as they may get reworked. It does not implement modular / incremental validation

[DrJonasWestman]

Great job!

It does not implement modular / incremental validation

I have not tried to execute it yet, but I think it does by looking at the way the shapes are linked.

[hartig]

Thanks @kentthang010 !

@DrJonasWestman, thanks for taking an initial look. Can you please take a closer look to check that the file captures what you need.

We can also discuss it during our call on Friday. In fact, I already told @kentthang010 that the vocabulary may still change and, as a result, the shape definitions may need to be adapted as well.

[DrJonasWestman]

I will happily do that but I think it makes more sense if I do it after our meeting on Friday.
Even with the current vocabulary there are some uncertainties that makes it hard to evaluate whether or not the shapes are complete enough.
Most importantly, we need to decide whether or not we want to assume that the verification will run on a graph with inference from the vocabulary or not.

[hartig]

I will happily do that but I think it makes more sense if I do it after our meeting on Friday.

Makes sense.

Most importantly, we need to decide whether or not we want to assume that the verification will run on a graph with inference from the vocabulary or not.

My initial reaction would be that we shouldn't make this assumption because it would add another step to the validation process: some inferencing component would need to have the vocabulary loaded and run the inference whenever validation needs to take place. But I am happy to hear arguments in favor of making the assumption.

Having said that, we can require the fed.descriptions to contain relevant triples that our current example fed.descriptions do not have (like rdf:type triples). Maybe that would already solve the issue.

[hartig]

@kentthang010 With PR #597 merged, you can resume the work on the SHACL shapes for the feddesc vocabulary.