topquadrant / shacl-js Goto Github PK

The idea of the SHACL-JS layering (as written in the W3C WG Note) is to be only tied to a minimal API, similar to the RDFJS task force's. This API can be implemented easily by RDFLib but equally easily by wrappers over Jena objects. The constraint definitions (and the rdfquery API) only use that API and are therefore, in principle, platform neutral.

Currently there is only one dist file and that includes rdflib. We need to generalize this again so that the src files can be turned into a .js file that can be included into other environments - either other .js base APIs or something completely different like a Nashorn-based implementation that uses Jena objects at runtime. Such a set-up is currently supported by the sibling SHACL API (for Java), where Jena Graphs are wrapped into JS proxies that provide a find method, as needed by the rest of the code. No rdflib is needed for that.

Looking at specific tasks, I believe the first step would be to remove the dependency from TermFactory on rdflib (make this pluggable somehow). And, if there are similar cases, decouple them too. Ideally, the bridge to rdflib is isolated to rdflib-graph.js only. Once we have this separation, the second step would be to define a second gulp target which produces a variation of dist/shacl.js that does not include rdflib and basially just bundles the other src/*.js files into a single file. Maybe let's rename the current shacl.js to shacl-rdflib.js.

It seems the examples of the SHACL playground use a shape graph with an HTTPS URI for the sh: prefix while the W3C Rec mentions an HTTP URI.

I noticed that because when I am copy-pasting my own shapes, none gets registered after clicking 'Update'.

The data used is from an example at https://www.w3.org/TR/shacl/#ClosedConstraintComponent

I am using the SHACL playground at https://shacl.org/playground/

data graph:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex:  <http://example.com/ns#> .

ex:Alice
	a ex:Person ;
	ex:ssn "987-65-432A" .
  
ex:Bob
	a ex:Person ;
	ex:ssn "123-45-6789" ;
	ex:ssn "124-35-6789" .
  
ex:Calvin
	a ex:Person ;
	ex:birthDate "1971-07-07"^^xsd:date ;
	ex:worksFor ex:UntypedCompany .

If I use the following shape graph:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex:  <http://example.com/ns#> .

ex:PersonShape
	a sh:NodeShape ;
	sh:targetClass ex:Person ;    # Applies to all persons
	sh:property [                 # _:b1
		sh:path ex:ssn ;           # constrains the values of ex:ssn
		sh:maxCount 1 ;
		sh:datatype xsd:string ;
		sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ;
	] ;
	sh:property [                 # _:b2
		sh:path ex:worksFor ;
		sh:class ex:Company ;
		sh:nodeKind sh:IRI ;
	] ;
	sh:closed true ;
	sh:ignoredProperties ( rdf:type ) .

I get the expected validation errors. However, the following shape graph in JSON-LD should be equivalent:

{
    "@context": {        
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "sh": "http://www.w3.org/ns/shacl#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "ex": "http://example.com/ns#"
    },

	"@id" : "ex:PersonShape",
	"@type" : "sh:NodeShape",
	"sh:targetClass" : "ex:Person",
	"sh:property" : [
		{
			"sh:path" : "ex:ssn",
			"sh:maxCount" : 1,
			"sh:datatype" : "xsd:string" ,
			"sh:pattern" : "^\\d{3}-\\d{2}-\\d{4}$"
		},
		{
			"sh:path" : "ex:worksFor",
			"sh:class" : "ex:Company",
			"sh:nodeKind" : "sh:IRI"
		}
	],
	"sh:closed" : true,
	"sh:ignoredProperties" : [ "rdf:type" ]
}

and when it is used, no validation errors are reported.

Your certificate created by LetsEncrypt expired the 17th of January for the website https://shacl.org

I tested on the playground with the following shape:

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <http://example.org/> .

ex:ClassShape a sh:NodeShape ;
  sh:targetClass ex:C ;
  sh:property [
    sh:path ex:p ;
    sh:maxCount 1
  ] .

As expected, the following instance has no violation:

@prefix ex: <http://example.org/> .

<tag:b0> a ex:C ; ex:p 0 . 
<tag:b1> a ex:C ; ex:p 1 .

However, if I use blank nodes as follows, I get a max count violation:

@prefix ex: <http://example.org/> .

_:b0 a ex:C ; ex:p 0 . 
_:b1 a ex:C ; ex:p 1 .

This should make no difference according to the standard, right?

The following works on the JSON-LD Playground (1) but yields this error when entered as the Data Graph on the SHACL Playground: jsonld.RdfError: Could not expand input before serialization to RDF

{
  "@context": {
    "@base": "http://schema.org",
    "@vocab": "/"
  },
  "@type": "InteractionCounter",
  "interactionType": {
    "@id": "CommentAction"
  }
}

I'm not familiar enough with rdflib to know the issue off hand, but I assume there may be an overriding configuration for @base.

(1): https://json-ld.org/playground/

Just wondering what the status of this project is - specifically whether there are plans to make the lib compatible with Node.js?

The SHACL playground does not seem to understand implicit target classes, i.e. node shapes that are both an rdfs:Class and a sh:NodeShape implicitly have a reflexive sh:targetClass property.

(Moved from TopQuadrant/shacl#20 to this repo).

Go to http://shacl.org/playground/, select "example in Turtle" and add

schema:gender "hermaphrodite"

This constraint:

    sh:property [
        sh:path schema:gender ;
        sh:in ( "female" "male" ) ;
    ] ;

Causes this result:

[
	a sh:ValidationResult ;
	sh:resultSeverity sh:Violation ;
	sh:sourceConstraintComponent sh:InConstraintComponent ;
	sh:sourceShape _:n3 ;
	sh:focusNode <http://example.org/ns#Bob> ;
	sh:value "hermaphrodite" ;
	sh:resultPath schema:gender ;
	sh:resultMessage "Value is not in Blank node _:n11" ;
] .

"Blank node _:n11" in sh:resultMessage is not very useful.

Hi,
I was testing the service, and I am trying to understand how the validation of datetimes should work. For instance,
my SHACL (https://github.com/rapw3k/DEMETER/blob/master/models/SHACL/demeterAgriProfile-SHACL.ttl) has the definition:

https://astrea.linkeddata.es/shapes#cec13f824650b91401ee4d9e7051141d
a sh:PropertyShape ;
rdfs:isDefinedBy https://github.com/GSMADeveloper/NGSI-LD-Entities/blob/master/definitions/Agri-Parcel.md ;
rdfs:label "lastPlantedAt"@en , "Indicates the date when the crop was last planted." ;
sh:datatype xsd:dateTime ;
sh:description "Indicates the date when the crop was last planted." ;
sh:name "lastPlantedAt"@en ;
sh:nodeKind sh:Literal ;
sh:path fiware:lastPlantedAt ;
sh:pattern "-?([1-9][0-9]{3,}|0[0-9]{3})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5]0-9?|(24:00:00(\.0+)?))(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?" .

I tried making a bad example that will report incorrect date (https://github.com/rapw3k/DEMETER/tree/master/models/examples). I tried:

https://uri.fiware.org/ns/data-models#lastPlantedAt "test-bad-pattern"^^xsd:dateTime .
and
https://uri.fiware.org/ns/data-models#lastPlantedAt "test-bad-pattern" .

both none report error. How these should work ?

thanks

We should enable some kind of CI check for PR, so we can run the tests automatically

Travis, CircleCI or any other system would do.

Web tests are not running in travis for every build, only the node tests.

A way of running these tests automatically as part of the build process must be found.

I am messing around in the shacl playground and added a subclass to the Person class in the example: Child

@prefix dash: <http://datashapes.org/dash#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl:   <http://www.w3.org/2002/07/owl#>  .

schema:Person
    a sh:NodeShape , owl:Class ;
    sh:property [
        sh:path schema:givenName ;
        sh:datatype xsd:string ;
        sh:name "given name" ;
    ] ;
    sh:property [
        sh:path schema:birthDate ;
        sh:lessThan schema:deathDate ;
        sh:maxCount 1 ;
    ] ;
    sh:property [
        sh:path schema:gender ;
        sh:in ( "female" "male" ) ;
    ] ;
    sh:property [
        sh:path schema:address ;
        sh:node schema:Address ;
    ] .

schema:Child
    a sh:NodeShape , owl:Class ;
    rdfs:subClassOf schema:Person ;
    .

Now my understanding of subclasses is that the properties of the parent class are inherited. However, when I change the schema:Person into schema:Child in the data graph it does not seem like the properties are inherited correctly (it seems to ignore the sh:lessThan constraint that is violated:

@prefix ex: <http://example.org/ns#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:Bob
    a schema:Child ;
    schema:givenName "Robert" ;
    schema:familyName "Junior" ;
    schema:birthDate "1971-07-07"^^xsd:date ;
    schema:deathDate "1970-09-10"^^xsd:date ;
    schema:address ex:BobsAddress .

Why are the properties of Person not inherited to child in this case?

Hi, I'd like to use the library, but the code in the README is quite slow. However when I go to shacl-playground and cut/paste the same shapes and data, I see that it's actually pretty performant. How do I get the kind performance I see on the playground?

Thanks!

There is currently a misalignment between the versions of dash.ttl and dash.js (and related files) between this shacl-js repo and the sibling shacl repo (for the public Java API). Yet another version lives in the private TopQuadrant repo from which the next product releases are built.

All these should be using the same code, where possible. In particular though, the dash.ttl should have the same content and offer the same features, because that namespace is supposed to be stable and reliable.