SHACL: Constraint on foaf:primaryTopic

[andrea-perego]

The current SHACL constraints raise a sh:Violation when an instance of foaf:primaryTopic is missing from a dcat:CatalogRecord, even when its inverse foaf:isPrimaryTopicOf is present.

This results in a validation error for GeoDCAT-AP records generated from INSPIRE / ISO 19115 ones, as, in such cases, foaf:isPrimaryTopicOf is more frequently used.

Is there a strong reason why the use of foaf:isPrimaryTopicOf instead of foaf:primaryTopic is not satisfying the requirements underlying the relevant constraint?

[jakubklimek]

One obvious reason is the simplicity of applications working with DCAT-AP data. It is simpler to expect one of the inverse property pair than to account for both. Especially, when the problem can be addressed at the data publisher side by adding the inverse property there.

[bertvannuffelen]

I share the remark of @jakubklimek.

In general inverse-named properties (propA and propB) create challenges on several levels:

• does the inverse relation always holds? So it holds that s1 propA o1 would mean o1 propB s1 and s2 propB o2 would mean o2 propA s2
• cardinality constraints on propA and propB are aligned
• does a catalogue must contain propA and propB always? If not, what is the prime property to be shared: propA or propB?

Many of these questions are dropped if only direction (typically the most natural one) is part of the specification. The other is than a supportive property for implementations.

[bertvannuffelen]

proposal:

no change to the specification.

[bertvannuffelen]

Since no objections have been formulated to this resolution, no adaptations to the shacl shape are included.