DatasetMetadata RDFS: URI-typed Dataset attributes have no rdfs:domain since 489c5c5 — class binding not derivable from RDFS, while SHACL still requires them

[Haigutus]

Affected artifacts

Ref	NCP/**/RDFS/DatasetMetadata-AP-Voc-RDFS2020.rdf	rdfs:domain / rdf:Property
ncp-v2-4-1 @ 6c13098b	not affected	51 / 49
ncp-v2-4-2 @ a115032b (current HEAD)	affected	40 / 49
main @ d113c048 (2.5 draft, NCP/CurrentRelease)	affected	40 / 49

Introduced by commit 489c5c51ac4f (2026-05-27, "Correct RDFS for NCP dataset metadata to
remove the record <rdfs:domain rdf:resource="http://www.w3.org/ns/dcat#Dataset"/> for
literal attributes with datatype <cims:dataType rdf:resource="#URI"/>").

Problem

After that commit, these 11 properties are still declared as rdf:Property with
cims:dataType #URI, cims:multiplicity and stereotypes, but carry no rdfs:domain
(or any other class linkage):

dcterms:accessRights, dcterms:accrualPeriodicity, dcterms:conformsTo,
dcterms:license, nc:processType (type), dcterms:publisher, dcterms:source,
dcterms:spatial, dcterms:type, dcatcim:usedSettings, prov:wasGeneratedBy.

For tooling that derives the exchange schema from the RDFS2020 vocabulary (which class
carries which attribute), these properties are orphaned — they can no longer be
associated with dcat:Dataset, so generated serializers/validators silently drop the
corresponding header statements. All string-typed Dataset attributes (dcat:keyword,
dcterms:title, dcterms:description, dcterms:identifier, …) still carry
rdfs:domain, so the vocabulary is now internally inconsistent about how attribute
membership is expressed.

Meanwhile the constraints artifact of the same release still binds all of them to the
Dataset/DifferenceSet node shapes and even requires some of them, e.g. in
NCP/SHACL/DatasetMetadata-AP-Con-SHACL.ttl (ncp-v2-4-2):

dm:conformsTo-cardinality
        rdf:type        sh:PropertyShape;
        sh:message      "Cardinality violation. Lower bound shall be 1";
        sh:minCount     1;
        sh:path         dcterms:conformsTo;
        sh:severity     sh:Violation .

So an implementation that derives its writer from the RDFS cannot emit
dcterms:conformsTo, and the emitted document then fails the release's own SHACL.

If the motivation was RDF-semantics hygiene (a global rdfs:domain on shared
dcterms/dcat vocabulary terms entails class membership for every user of the term),
that concern applies equally to the string-typed properties that kept their domain —
and the RDFS2020 application-profile files are already profile-scoped artifacts, not
global vocabulary definitions.

Reproduce

git diff 489c5c51ac4f^ 489c5c51ac4f -- NCP/CurrentRelease/RDFS/DatasetMetadata-AP-Voc-RDFS2020.rdf
# 11 properties lose <rdfs:domain rdf:resource="http://www.w3.org/ns/dcat#Dataset"/>

Questions / proposal

1. If the removal is intentional: what is the intended machine-readable way to derive,
   from the RDFS package alone, that these properties are exchanged on dcat:Dataset?
2. If profile-scoped domains are acceptable (as for the string-typed attributes),
   please restore rdfs:domain for the 11 URI-typed properties on ncp-v2-4-2-line
   and main so the vocabulary is consistent and matches the SHACL.

[griddigit-ci]

It was intentional after long discussion. Assigning to Vladimir to comment

[Haigutus]

How can then one derive under what class are the attributes? Should one assume that any class can contain them?

[VladimirAlexiev]

@Haigutus as you mention, the semantics of rdfs:domain is that every instance using the property becomes of that class.
But dct:title is not only used on Dataset, it's also used on Ontology. So with RDFS reasoning, suddenly your Ontologies get mixed up with your Datasets.

@griddigit-ci, rdfs:domain should be remived from data props too.

Changing the definition of an external term is ontology hijacking and should not be done. You mention "scoped": please define exactly what you mean by that. There are no "scopes" in RDF.

CIM uses strict domains and ranges for its own terms. But when it reuses an external tool, it cannot impose such restrictions on it. CIM UML-to-RDF tooling had a hard time coming to grips with this, and even mangled DCT term URLs.

Serialization tooling should also adapt to derive property attachment from SHACL.

Alternatively, CIM could use schema:domainIncludes instead of rdfs:domain for these props. But tooling still needs to be changed.

[Haigutus]

I am lost, what I need is a schema (shacl is not schema). Dcat itself has the same approach as cim, eg attributes are linked to a class with rdf:domain https://www.w3.org/ns/dcat3.ttl. I am fine with change, but not for: - changing core logic month to month - without consistency (changes in some profiles/attributes but not in all) - without documentation and sound reasoning why

[Haigutus]

@VladimirAlexiev After researching this, I agree with the rdfs:domain usage issue, but I still object to how the change was implemented, because it breaks a core principle of the current setup: the exchange structure is pure-RDFS-contained. Today, which classes exist and which attributes each one carries is fully expressed in the RDFS vocabulary. 489c5c5 removes part of that structure from RDFS with no replacement, effectively pushing it into SHACL and that is the part I object to, independently of the rdfs:domain semantics.

Agreed on the semantics: rdfs:domain on an externally-owned term (dcterms:*, prov:*) is over-committal. Its RDFS entailment types every user of the term into the domain class, so dcterms:title rdfs:domain dcat:Dataset pollutes the external vocabulary and any titled resource, including an ontology, gets inferred to be a dcat:Dataset. It does not belong on terms CIM doesn't own. No disagreement.

But two problems with the change as it stands:

1. It's internally inconsistent. rdfs:domain was removed from the 11 URI-typed Dataset attributes but kept on the string-typed ones (dcterms:title, dcterms:description, …). The vocabulary now expresses attribute membership two different ways in one file.

2. It removed the class↔attribute link with no vocabulary-level replacement. Which attributes a class carries is core schema structure, and it must stay expressible at the RDFS/vocabulary layer a plain statement in the RDFS file, not only in a separate SHACL artifact. After the change those 11 properties are rdf:Property records with a datatype, multiplicity and stereotypes but nothing binding them to dcat:Dataset, so any RDFS-driven tool that derives the exchange schema (which class carries which attribute) silently drops them while the SHACL still requires them. Removing a construct is only acceptable if an equivalent, vocabulary-expressible alternative replaces it.

On SHACL: its purpose is to express constraints / validation over data cardinality, value rules, conditional shapes and it is the right place for those. It is not the place to define the structure of the exchange (which classes exist, which attributes they carry). That structural backbone has to live in the RDFS vocabulary; if it lives only in SHACL, the vocabulary stops being a self-standing schema and RDFS-driven serializers/generators have nothing to derive from.

Proposal: keep the linkage in the vocabulary, without polluting external terms:

• CIM-namespace-owned properties (nc:*, dcatcim:*, cim:*): keep rdfs:domain. CIM owns them, so a strict domain is correct and pollutes nothing.
• Externally-owned / reused properties (dcterms:*, prov:*): use schema:domainIncludes instead of rdfs:domain.

schema:domainIncludes is schema.org's purpose-built, non-inferential counterpart to rdfs:domain — it records "this property is expected on this class" without the entailment that types every user into the class. schema.org introduced it for exactly this case (properties reused across many classes, where rdfs:domain over-commits). It carries no logical force, so it leaves the external term's meaning untouched while keeping the class linkage present and machine-readable, as a flat per-record triple that maps onto the RDFS2020 format 1:1:

<!-- reused (external) terms non-inferential linkage, no pollution -->
<rdf:Description rdf:about="http://purl.org/dc/terms/accessRights">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <cims:dataType rdf:resource="#URI"/>
  <schema:domainIncludes rdf:resource="http://www.w3.org/ns/dcat#Dataset"/>
  <cims:multiplicity rdf:resource="http://iec.ch/TC57/1999/rdf-schema-extensions-19990926#M:0..1"/>
  <cims:stereotype>dcterms</cims:stereotype>
</rdf:Description>

<!-- CIM-owned terms rdfs:domain stays, CIM owns it -->
<rdf:Description rdf:about="https://ap-voc.cim4.eu/DatasetMetadata#usedSettings">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:domain rdf:resource="http://www.w3.org/ns/dcat#Dataset"/>
  <!-- … -->
</rdf:Description>

(with xmlns:schema="https://schema.org/"). Datatype, multiplicity and stereotype stay exactly where they are; only the linkage predicate changes, and only for reused terms. This is also the split DCAT itself follows — rdfs:domain on its own dcat:* terms, nothing added to the dcterms:* it reuses.

Other options considered, for completeness:

• CIM sub-properties dm:accessRights rdfs:subPropertyOf dcterms:accessRights ; rdfs:domain dcat:Dataset. Pure RDFS and fully correct (you own the sub-property), but it changes the serialized property URI, which breaks interoperability with generic DCAT/DCT consumers defeating the point of reusing Dublin Core.
• owl:Restriction on the class dm:DatasetMetadata rdfs:subClassOf [ owl:onProperty dcterms:accessRights ; owl:maxCardinality 1 ]. Correct, keeps the term URIs on the wire, can even carry cardinality but it introduces OWL blank-node restrictions foreign to the flat RDFS2020 record style.

schema:domainIncludes is the least invasive of the three for this format: a one-line-per-record swap, no wire-format change, no OWL, no SHACL.

Proposal:

• Apply the convention consistently to all reused terms (URI- and string-typed alike), and keep CIM-owned terms on rdfs:domain.
• Keep the class/attribute structure in the RDFS vocabulary with SHACL layering constraints on top, not carrying the structure.
• Document the convention clearly in the repository README (owned → rdfs:domain, reused → schema:domainIncludes), so profile authors and downstream tooling can rely on it rather than rediscovering it per release.

[VladimirAlexiev]

Respectfully, please stop using LLM to write issues and comments. People dont have time to read and answer such missives point by point.

About 1: data props should also stop hijacking "domain", cc @griddigit-ci , @Sveino .

About the role of SHACL: it expresses expectations about RDF data. Which can mean validation, modeling, form generation. It is in fact heavily used for modeling, and even for UI generation (SHACL UI).

About RDFS: with the desire to reuse, CIM has outgrown pure RDFS. CIM has overly specific props, which is a main reason it has 7k props. (There are up to 50 conflicts on the last part of prop URLs after the dot). This is an anti-pattern, and external ontologies don't use it.

Apart from SHACL, there are 2 other ways to express prop attachment:

• owl:Restriction. It can express cardinality
• schema:domainInclusive. It cannot express cardinality

[VladimirAlexiev]

@Haigutus
You are wrong about DCAT: it attaches only 3 of its own props to DCT classes (Location and PeriodOfTime): that's no hijacking. But if you read the spec (or just the UML diagram), you'll see it reuses maybe 20 external props (eg dct:title). And it leaves them alone.

[Haigutus]

@VladimirAlexiev yes, I just saw it uses domain, but on further checking I saw that only for attributes within dcat ownership.

I agree, that CIM does things not the way other standards do and it causes issues using correct tooling out of the box. I also agree that we should move direction other standards have moved and not invent the wheel.

That said I must strongly disagree how currently the progression is done

• This was marked as minor/bugfix change, but brakes existing working tooling - thus it must be a major change, with testing, communication, IOP-s etc
• This change was done partially for header and the rest of RDFS still has domain conflicts even in cim - so this fix, fixed nothing for standard tooling
• SHACL for cim profiles is not really ready, more of a beta that still evolves (in my opinion). For now rdfs and shacl should overlap, to validate that shacl can be used for same usecase and is valid.

My point is

• Apply version management process.
• Don't brake legacy approach/tooling, if possible. (I would say that switching domain to domainIncludes reduces the impact significantly)
• Plan the change over all schemas.

Not sure if you have these sayings, but this issue brings to my mind two

Rome was not built in a day.

Dont burn the old hat before new one is on your head.