SHACL rules differ in shacl vs html directory (e.g byteSize)

[barthanssens]

There seems to be a difference between the separate "HTML" SHACL files and the (aggregated ?) version published in the SHACL directory

E.g. https://github.com/SEMICeu/DCAT-AP/blob/master/releases/3.0.0/html/shacl/shapes.ttl still lists dcat:byteSize as type xsd:decimal, while https://github.com/SEMICeu/DCAT-AP/blob/master/releases/3.0.0/shacl/dcat-ap-SHACL.ttl uses the correct type xsd:nonNegativeInteger

[barthanssens]

Also the other way round: the shacl/dcat-ap-SHACL explicitly checks if e.g. accessURL is an rdfs:Resource, while the html/shacl/shapes.ttl does not (nor does html/shacl/ranges.ttl)

[NielsHoffmann]

I also noted this discrepancy, in relation to the GeoDCAT-AP 3.0.0 pilot...
e.g. DataSet spatialResolutionInMeters is only specified as maxCount 1 and datatype xsd:decimal in the separate shapes.ttl.

Whereas in the dcat-ap-SHACL.ttl it is specified as xsd:decimal as well as nodeKind Literal.

The respec document only specifies the xsd:decimal property. So I tend to believe the seperate files are the 'official correct' ones. This poses a problem with the GeoDCAT pilot though, as the GeoDCAT-AP shacl file seems to be based on the dcat-ap-SHACL file.

[init-dcat-ap-de]

My guess would be that the shapes in releases/3.0.0/shacl/dcat-ap-SHACL.ttl are the "official" ones. They use the uuids for every single property instead of blank nodes and that was a planned improvement, afaik. (So you can easily deactivate shapes and add error messages in your language.)

The need for nodeKind "Literal" is implicit if you use a data type. The range is a literal typed as xsd:decimal.

[NielsHoffmann]

The decision to use uuids for properties is a seperate issue/decision from the decision to merge all shapes into 1 file.

I think it is indeed very good to have unique names for each individual property.
But I think it is actually a 'cleaner architecture' to provide separate files for the different levels of constraints, the way the original shapes in the /html/shacl/ folder are organized.

For those that want all constraints in one file, it is easier to merge the separate files into one, then it is to provide 1 file and leave it to the users to split it out again into separate files.
Also while authoring/maintaining the shacl files I think it is far easier to work with multiple small files that one big one.

The scenarios I would typically implement are checking for required properties (which is what the shapes.ttl specifies) before checking the range or recommended properties. So from that perspective the different shacl files make perfect sense to me.

[barthanssens]

Well, I also prefer separate files, but one big file is also fine with me... But at least the results should be the same :-)