Consider replacing `dcterms:relation` with `SIO:000008` as default attribute predicate in DCAT-AP+

[StroemPhi]

Affected: dcat_ap_plus.yaml - has_quantitative_attribute and has_qualitative_attribute slot definitions
Severity: Design improvement
Status: Proposal - requires team discussion

Problem: dcterms:relation is the current slot_uri for the DCAT-AP+ attribute pattern slots. It is semantically extremly thin - it asserts only that "some relationship exists" between an entity and its attribute. In practice, every domain profile that needs meaningful RDF output will probably overide this predicate (e.g. ChemDCAT-AP uses SIO:000008). This suggests the default is too conservative to be useful.

Additionally, in OBO Foundry ontologies, dcterms: predicates are routinely retyped as owl:AnnotationProperty for use in ontology-level metadata (provenance of terms, editorial annotations). When these predicates are simultaneously used as object properties on instance data in the same knowledge graph, this creates an OWL DL violation. Domain profiles operating in a BFO/OBO ecosystem will always need to avoid using DCTerms predicates as object properties on instance data.

Proposal: Adopt SIO:000008 (has attribute) as the DCAT-AP+ default slot_uri for both has_quantitative_attribute and has_qualitative_attribute.

Justification:

• SIO is BFO-aligned, consistent with the PROV-O bridge story via the published BFO → PROV-O mapping
• SIO:000008 is semantically precise for the attribute pattern
• SIO is open-source and actively maintained
• Eliminates the need for domain profiles to override the default
• Adds SIO as a new dependency to DCAT-AP+ (alongside PROV-O, DCTerms, QUDT), but QUDT is already a non-W3C dependency, so the precedent exists

SchemaVer impact: REVISION (changes slot_uri of existing slots --> existing RDF data would use a different predicate)

[StroemPhi]

Thinking abou this in a specific context, it might not be such a good idea to switch to SIO:has attribute, since it is defined as:

has attribute is a relation that associates a entity with an attribute where an attribute is an intrinsic characteristic such as a quality, capability, disposition, function, or is an externally derived attribute determined from some descriptor (e.g. a quantity, position, label/identifier) either directly or indirectly through generalization of entities of the same type.

to me this means that the attribute must always be some kind of BFO:SDC or IAO:ICE. But let's consider the use case, where one wants to use the has_qualitative_attribute slot to relate the manufacturer (the actual org not the label of the org) to a device. DCTerms relation would totally allow that and in a device specific sub-profile one could add subslots to account for this more properly.