Closed andrea-perego closed 2 years ago
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.
I share the remark of @jakubklimek.
In general inverse-named properties (propA and propB) create challenges on several levels:
s1 propA o1
would mean o1 propB s1
and s2 propB o2
would mean o2 propA s2
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.
proposal:
no change to the specification.
Since no objections have been formulated to this resolution, no adaptations to the shacl shape are included.
The current SHACL constraints raise a
sh:Violation
when an instance offoaf:primaryTopic
is missing from adcat:CatalogRecord
, even when its inversefoaf: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 offoaf:primaryTopic
is not satisfying the requirements underlying the relevant constraint?