Add SHACL constraints

[KentThang]

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.

[KentThang]

Latest commit rewrites feddesc.shacl.ttl to fit the new vocabulary! I wasn't quite sure how to handle the new wrapper conditions

wrappers associated with a federation member whose interface has fd:GenericWebAPIProtocol as the fd:supportedProtocol, must have an fd:rmlTriplesMaps property; and for wrappers associated with a federation member whose interface has fd:BoltProtocol or fd:GraphQLProtocol as the fd:supportedProtocol, the wrapper must have an fd:mappingConfiguration property.

I solved it by adding two new shapes RMLWrapperShape and MappingConfigWrapperShape as well as an sh:or in WrappedFederationMemberShape that makes sure the wrapper conditions above are enforced.

Not sure if this is the cleanest solution, let me know if there is a better one!

[KentThang]

Latest commit resolves all PR comments.

Although, while testing, I noticed that ExampleFederation.ttl fails validation because fd:rmlTriplesMaps points to an rdf:List while the shape applies fd:RmlTriplesMapShape directly to fd:rmlTriplesMaps.

So in other words, I think the validator currently validates the RDF list node itself against fd:RmlTriplesMapShape, instead of validating the individual rml:TriplesMap elements inside the list.

At this point, do we want to:

1. just simplify the constraint to check that fd:rmlTriplesMaps exists and points to an RDF node/list or
2. add proper RDF list traversal?

[hartig]

Latest commit resolves all PR comments.

Review coming up..

Although, while testing, I noticed that ExampleFederation.ttl fails validation because fd:rmlTriplesMaps points to an rdf:List while the shape applies fd:RmlTriplesMapShape directly to fd:rmlTriplesMaps.

So in other words, I think the validator currently validates the RDF list node itself against fd:RmlTriplesMapShape, instead of validating the individual rml:TriplesMap elements inside the list.

Indeed. That's not how it should be.

At this point, do we want to:
1. just simplify the constraint to check that fd:rmlTriplesMaps exists and points to an RDF node/list or
2. add proper RDF list traversal?

The latter would be better. I think you should be able to use the SHACL Property Paths feature to navigate from the root list element (the object of the fd:rmlTriplesMaps triple in the federation description) to every rdf:first object to check that each of these objects either is rdf:nil or satisfies fd:RmlTriplesMapShape. The corresponding SPARQL property path expression would be rdf:rest*/rdf:first

[KentThang]

Latest commit resolves the PR comments above. Both the interface and federation member shapes now use the same pattern (sh:xone in the abstract shape and then sh:node in the more refined shapes) and I have also added RDF list traversal for fd:RMLWrapperShape.

[hartig]

From my perspective, this PR looks good now.

@DrJonasWestman what do you think?