RegionShape and DatasetShape could select by OEO class instead of by predicate

[jh-RLI]

Description of the issue

Five of the eight node shapes in oekg/shapes/oekg_shapes.ttl select their focus nodes with
sh:targetClass and an OEO class. Three do not — they use sh:targetObjectsOf and select by
the predicate that points at a node instead of by what the node is:

Shape	selects by	could select by
ex:RegionShape	oeo:OEO_00020220, oeo:OEO_00020222	oeo:OEO_00020032 (study region), oeo:OEO_00020036 (interacting region)
ex:DatasetShape	oeo:OEO_00020437, oeo:OEO_00020436	oeo:OEO_00030029 (exogenous data), oeo:OEO_00030030 (endogenous data)
ex:CommonShape	ten predicates	— see below, this one must stay as it is

For the first two the classes are already named in the shape itself: ex:ScenarioShape constrains
exactly those predicates with sh:class to exactly those classes. So the shape already knows what
these nodes are; it just does not use that to find them.

Why this is worth changing. Selecting by class says what the shape is about — "this is what a
study region must look like" rather than "this is what a thing somebody pointed at with
has-study-region must look like". It also makes the shape's own structure uniform: eight shapes,
one targeting style, instead of five-and-three. And a region that exists but is not currently
linked to any scenario is still a region, and would be checked.

Ideas of solution

ex:RegionShape
    a sh:NodeShape ;
    sh:closed true ;
    sh:ignoredProperties ( rdf:type ) ;
-   sh:targetObjectsOf oeo:OEO_00020220 ;   # has_study_region
-   sh:targetObjectsOf oeo:OEO_00020222 ;   # has_interacting_region
+   sh:targetClass oeo:OEO_00020032 ;       # study region
+   sh:targetClass oeo:OEO_00020036 ;       # interacting region
    ...

ex:DatasetShape
-   sh:targetObjectsOf oeo:OEO_00020437 ;   # has information input
-   sh:targetObjectsOf oeo:OEO_00020436 ;   # has information output
+   sh:targetClass oeo:OEO_00030029 ;       # exogenous data
+   sh:targetClass oeo:OEO_00030030 ;       # endogenous data

Measured, not assumed

Run against a current OEKG export (13,700 triples, 55 scenario bundles, 2026-09-14) with
pyshacl 0.28.1 — the same validator the oeplatform REST API uses — validating each bundle's
subgraph with the shape as it is and with the two shapes converted:

	conforming	violations
sh:targetObjectsOf (today)	0/55	218
sh:targetClass (converted)	0/55	218

Identical, message for message. Four hand-built cases agree too: a correctly typed region, an
untyped one, a wrongly typed one, and a typed one missing its label all produce the same result
either way — because ex:ScenarioShape's sh:class already catches a wrong or missing type, and a
correctly typed node is selected by both styles.

The one case where they differ — and what it costs

A node that is untyped and violates the shape's own rules is reported three times today and
once after the change:

Region linked from a scenario, no rdf:type, no rdfs:label, plus a property the shape forbids

today       3 violations:  "…is closed"
                           "Region target: This should be a string and have exactly one label."
                           "Scenario target: This should end in class study region"

converted   1 violation:   "Scenario target: This should end in class study region"

Nothing goes unreported — the node is still refused, by ex:ScenarioShape's sh:class. What is
lost is the detail: today the report also says what else is wrong with the node, which is useful
when fixing it. That is a real trade and worth deciding deliberately rather than discovering later.

A middle option exists: keep both targeting styles on those two shapes. SHACL unions targets, so
sh:targetClass and sh:targetObjectsOf together select typed nodes and linked-but-untyped ones,
and nothing is lost at all. That costs two extra lines per shape and no behaviour.

ex:CommonShape must stay as it is

Not a matter of taste. It targets the objects of ten predicates — study descriptor tag, author,
sector division, sector, technology, contact person, organisation, funding source, energy carrier,
scenario type. Those objects are OEO terms picked from the shape's own sh:in lists, and in the
OEKG graph they are bare IRIs with no type triple at all. A sh:targetClass would therefore
select nothing and the shape would silently stop checking.

That is the dangerous version of this change: it would look tidier and validate nothing. Worth
saying out loud in this issue so nobody "finishes the job" later.

Consumer to be aware of

oeplatform fetches this file at a pinned commit
(OpenEnergyPlatform/oeplatform, setting OEKG_SHAPES_PINNED_COMMIT, currently
b4604e02060624b381bdbe2f872df94cfd0f5630) and validates every API write against it. A change here
reaches that platform only when the pin moves, which is the intended behaviour — the validator does
not change without a deploy. The measurement above was taken with that consumer's own validator, so
the two agree by construction.

Workflow checklist

• I am aware of the workflow in CONTRIBUTING.md

[jh-RLI]

@stap-m
Please have a look this and let me know if it makes sence to you :) It would change the OEKG a bit. AI raised this during the Bundles API implementation.

[jh-RLI]

A second one, from the same measurement: has scenario year value is typed as an instant

ex:ScenarioShape requires xsd:dateTime for oeo:OEO_00020440 (has scenario year value). A
scenario year is a year. The maintainer's note on this was that expressing "just a year" in the
shape seemed difficult — so here is what the data and the validator actually say.

xsd:gYear works

Checked with pyshacl 0.28.1, the validator the oeplatform API uses:

sh:datatype xsd:gYear    with "2020"^^xsd:gYear     →  conforms
sh:datatype xsd:dateTime with "2020"^^xsd:dateTime  →  violates

xsd:gYear is a standard XSD datatype meaning exactly a Gregorian year, and SHACL's sh:datatype
takes any datatype IRI. Nothing had to be invented and nothing is unsupported. So the difficulty
was not in the expressing.

What the demand for a dateTime has produced in the live graph

Current export, 13,700 triples, 55 scenario bundles — 1,218 values of this property, 51 distinct:

1,199 (98.4 %)	"2030-01-01T00:00:00"^^xsd:dateTime — a year, plus a first of January at midnight that nobody entered
19 (1.6 %)	"2020"^^xsd:dateTime — the honest value, and not a valid dateTime, so the shape rejects it
0	an actual date or time

Not one value in the graph carries a real day or time. The property has only ever held years.
The dateTime requirement has not captured information; it has manufactured 1,199 fake timestamps
to satisfy a type, and it rejects the 19 values that told the truth.

That inverts the usual repair story. A tool fixing the 19 would make them look like the 1,199 —
which is what
oeplatform#2449's year-dates repair
does, deliberately opt-in and with a warning printed at run time, precisely because it papers over
this rather than fixing it.

If the shape changes

Switching sh:datatype to xsd:gYear makes the 1,199 existing values violations, so it needs a
data migration in the same movement: strip -01-01T00:00:00 back to the year and re-type the
literal. That is mechanical and lossless — the suffix carries no information, as the table above
shows — but it is a write to the production graph and belongs with whoever runs that.

An sh:or of xsd:gYear and xsd:dateTime would accept both and need no migration. It would also
keep the 1,199 fake timestamps indistinguishable from real ones forever, so I would not recommend it
except as a transition step.

Not a decision for this repo alone

Two consumers to keep in mind: the browser UI writes this property, and the oeplatform REST API
validates every write against this shape at a pinned commit. Whichever way it goes, the UI's write
path decides what the next thousand values look like.