SHACL constraints on Turtle Input

[KaiTries]

Currently there is no validation done on turtle input except to check if it is valid rdf. SHACL would enable us to precisely define what is valid input and what not.

This would be a big undertaking since we would need to first define what constitutes valid input for the different cases we have and then also implement the shacl validation.

Luckily rdf4j provides us with an API to validate graphs. So we only need to supply the shacl rules.

These are all the instances where we have some turtle input where we would need to define validity:

• Creation of workspaces
• Creation of artifacts
• Updating of workspaces
• Updating of artifacts

Defining valid input

In the current version of yggdrasil, when creating a workspace / artifact through turtle, some signifiers are automatically added to the representation. These need to be accounted for when defining the valid input. Further during the process of creating the entity, the RdfStoreVerticle will parse through the rdf string and replace all empty "<>" IRIs with the IRI of the resource.

Workspace example

@prefix jacamo: <https://purl.org/hmas/jacamo/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix websub: <http://www.example.org/websub#> .
@prefix hctl: <https://www.w3.org/2019/wot/hypermedia#> .
@prefix htv: <http://www.w3.org/2011/http#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .
@prefix hmas: <https://purl.org/hmas/> .

<http://localhost:8080/workspaces/sub> a hmas:ResourceProfile;
  hmas:exposesSignifier <http://localhost:8080/workspaces/sub/#updateCurrentWorkspace>,
    <http://localhost:8080/workspaces/sub/#registerArtifact>, <http://localhost:8080/workspaces/sub/#createSubWorkspace>,
    <http://localhost:8080/workspaces/sub/#unsubscribeFromWorkspace>, <http://localhost:8080/workspaces/sub/#deleteCurrentWorkspace>,
    <http://localhost:8080/workspaces/sub/#subscribeToWorkspace>, <http://localhost:8080/workspaces/sub/#getCurrentWorkspace>;
  hmas:isProfileOf <http://localhost:8080/workspaces/sub/#workspace> .

<http://localhost:8080/workspaces/sub/#updateCurrentWorkspace> a hmas:Signifier;
  hmas:signifies [ a sh:NodeShape;
      sh:class hmas:ActionExecution, jacamo:UpdateWorkspace;
      sh:property [
          sh:path prov:used;
          sh:minCount "1"^^xs:int;
          sh:maxCount "1"^^xs:int;
          sh:hasValue <http://localhost:8080/workspaces/sub/#updateCurrentWorkspaceForm>
        ]
    ] .

<http://localhost:8080/workspaces/sub/#updateCurrentWorkspaceForm> a hctl:Form;
  hctl:hasTarget <http://localhost:8080/workspaces/sub>;
  htv:methodName "PUT";
  hctl:forContentType "text/turtle" .

<http://localhost:8080/workspaces/sub/#workspace> a hmas:Workspace .

I left out the other signifiers for brevity, but when using yggdrasil with the hmas ontology and creating a workspace / artifact (slightly different but same functionality) with turtle, this skeleton representation will be created and then will be merged with the representation provided. A very simple but valid turtle request body could look like this:

@prefix ex: <http://example.org/> .
@prefix hmas: <https://purl.org/hmas/> .

<> a hmas:ResourceProfile ;
     ex:isExample ex:Test .

This would result in a workspace much like the base one above with the one additional triple added to the resourceIri.

Validity

This list is not exhaustive and just a collection of possible constraints we could implement:

• only one hmas:ResourceProfile triple per request and it must have a blank subject IRI
  • This way we can ensure that the merging goes as smoothely as possible and both representations are based on the same resourceProfile
• For subworkspaces the containment triple needs to be present otherwise it will create a root level workspace
• For updating entities you should not be allowed to delete certain signifiers (base ones).