shacl/v.1.2.1 - dct:publisher - skos:Concept should only be recommended

[init-dcat-ap-de]

We tested a few of our datasets with the EDP tool (https://www.europeandataportal.eu/shacl/) and found that some validation errors are falsely:

Example RDF: https://www.govdata.de/ckan/dataset/strassenverkehrsunfalle-in-schleswig-holstein-im-november-2007-vorlaufige-zahlen.rdf

XML:

    <dct:publisher>
      <foaf:Organization rdf:about="http://opendata.schleswig-holstein.de/organization/statistikamt-nord">
        <foaf:name>Statistisches Amt für Hamburg und Schleswig-Holstein - Anstalt des öffentlichen Rechts - (Statistikamt Nord)</foaf:name>
      </foaf:Organization>
    </dct:publisher>

Error:

    {
      "@id": "_:b6",
      "@type": "sh:ValidationResult",
      "focusNode": "http://opendata.schleswig-holstein.de/dataset/StaNord_CMS:55265",
      "resultMessage": "Value does not have class http://www.w3.org/2004/02/skos/core#Concept",
      "resultPath": "dct:publisher",
      "resultSeverity": "sh:Violation",
      "sourceConstraintComponent": "sh:ClassConstraintComponent",
      "sourceShape": "_:b7",
      "value": "http://opendata.schleswig-holstein.de/organization/statistikamt-nord"
    }

Possible reason/problem in the SHACL-files: The idea of the publisher is a concept, but the individual entity that is the publisher of a file is probably not a concept. But this argument might be to philosophically. DCAT-AP 1.2 has skos:Concept only as "recommended", so this error shouldn't be a violation.

Background dcat-ap.de is a German variation of dcat-ap. Our goal was, that all valid dcat-ap.de files are also valid dcat-ap files. We only reduced options and added specific fields.

GovData.de is (for example) a data portal where dcat-ap.de is used. GovData.de data is also collected by the EDP. We are now trying to improve the meta data quality, especially the dcat-ap compliance (https://www.europeandataportal.eu/mqa/govdata?locale=en).

Also posted at: https://gitlab.com/european-data-portal/mqa/shacl-validation/issues/4

[bertvannuffelen]

see #116 for feedback on the class membership discussion.

How the notion of mandatory, recommended and optional, the severity level impacts, can be discussed. Different aspects are here combined.

Some topics/questions:

• What does a mandatory class mean. There must be an instance of that class? That seems natural for catalog, dataset and distribution, but also for LicenseDocument? Because than you fall in the discussion of #116
• A recommended property: expressed as the cardinality must be more than 1, but must probably have a different severity level as error. But should it be warning or something different?
• the range constraint of a recommended property is as strict as the range constraint for an optional property. The reasoning that the range constraint skos:Concept is determined by the qualification that the class skos:Concept is recommended should not be done. Because that would mean that the range constraints can be qualified as mandatory, recommended or optional. The semantics of that is unclear.

[init-dcat-ap-de]

A recommended property: expressed as the cardinality must be more than 1, but must probably have a different severity level as error. But should it be warning or something different?

Shacl knows "Violation", "Warning" and "Info". So my approach is: Not conforming to a mandatory rule is a violation, not following an recommended rule is a warning and not having an optional class will be thrown as information.

A SKOS concept can be viewed as an idea or notion; a unit of thought. However, what constitutes a unit of thought is subjective, and this definition is meant to be suggestive, rather than restrictive. The notion of a SKOS concept is useful when describing the conceptual or intellectual structure of a knowledge organization system, and when referring to specific ideas or meanings established within a KOS.

I see this as a problem of the Shacl Shapes. While it is right that in the ontology the publisher might be described as a concept, some entity who is the publisher is probably not a concept. This is probably true for most of the SKOS:Concept rules.

[bertvannuffelen]

During WG 21 Oct 2021, it has been decided not to upgrade the historic SHACL representations and focus on the new representations.

[bertvannuffelen]

During WG 21 Oct 2021, it has been decided not to upgrade the historic SHACL representations and focus on the new representations.