Adds a feature of dimension anotations #202

tpluscode · 2024-09-24T14:29:09Z

This will add annotations, as required to achieve the functionality of targets or limits.

changeset-bot · 2024-09-24T14:29:13Z

🦋 Changeset detected

Latest commit: a3575ad

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
cube-link	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

meta/core.md

giacomociti · 2024-09-27T08:11:34Z

test/standalone-constraint-constraint/invalid.annotation-invalidRanges.ttl

+                    meta:annotationContext
+                        [
+                            sh:path <year> ;
+                            sh:minInclusive <https://ld.admin.ch/time/year/2020> ;


why two lower bounds?

That's a test cases which should fail

ah, I see, to check they are not accepted :-)

I tried to make this even more accurate but I seem to have hit a limitation of shat SHACL can do when there are multiple properties with same value. I failed to make a validation to catch for example

sh:minInclusive <https://ld.admin.ch/time/year/2020> sh:minExclusive <https://ld.admin.ch/time/year/2020>

tpluscode · 2024-09-27T08:13:37Z

meta/core.md

+In case of temporal dimensions, the constraint values are expected to be literals with datatypes `xsd:date`,
+`xsd:dateTime` or `xsd:gYear`, or the IRIs of [temporal entities](https://lindas.admin.ch/governance/core-entities/).


I could not find a simple enough way to include this in the validation shape

tpluscode · 2024-09-27T08:32:36Z

test/standalone-constraint-constraint/invalid.annotation-invalidRanges.ttl

+                    meta:annotationContext
+                        [
+                            sh:path <year> ;
+                            sh:minInclusive <https://ld.admin.ch/time/year/2020> ;


I tried to make this even more accurate but I seem to have hit a limitation of shat SHACL can do when there are multiple properties with same value. I failed to make a validation to catch for example

sh:minInclusive <https://ld.admin.ch/time/year/2020> sh:minExclusive <https://ld.admin.ch/time/year/2020>

tpluscode · 2024-09-27T08:37:31Z

validation/standalone-constraint-constraint.ttl

+                    [
+                        sh:property
+                            [
+                                sh:path [ sh:inversePath meta:annotationContext ] ;
+                                sh:minCount 1
+                            ]
+                    ]


I did not define a class for the annotation context so this is needed to distinguish them from actual key dimension because sh:path/^sh:path will find both. Would not have been needed if we used a different property to refer to the dimension in annotation context.

Kronmar-Bafu

Found a typo: cube:KeyDimension, not meta:KeyDimension. Rest looks good to me

test/standalone-constraint-constraint/invalid.annotation-invalidRanges.ttl

test/standalone-constraint-constraint/invalid.annotation-keyDimensions.ttl

test/standalone-constraint-constraint/invalid.annotation-missingValue.ttl

test/standalone-constraint-constraint/invalid.annotation-mixedConstraints.ttl

test/standalone-constraint-constraint/valid.annotation.ttl

validation/standalone-constraint-constraint.ttl

test/standalone-constraint-constraint/invalid.annotation-invalidRanges.ttl

Rdataflow · 2024-10-15T12:24:30Z

meta/core.md

+
+</aside>
+
+`schema:minValue` and `schema:maxValue` can be used to express a range of limit values.


@tpluscode it would be helpful for the reader to explicitly state lower limit values and upper limit values 😉 as there are also situations where only one sort occurs and this information is needed to check and display whether the values are within the acceptable range.

Good catch. We seem to have dropped that along the way - or at least I think we had that covered once.
In any case, we should include that somehow.
Either with different classes? I.e. meta:UpperLimit and meta:LowerLimit? Or maybe more elegant with schema:minValue/schema:maxValue instead of the generic schema:value?

Or would you see a case where a LIMIT could no specified to be an upper or lowr Limit @Rdataflow ? It would not really be a limit without that specification?

After a small chat with @Rdataflow, we both agree that the generic schema:value is not well suited for meta:Limit. At least for what we try to express here.

One thing we should distinguish is between the mathematical concept of a limit (or limes) and limit as we envisioned here. Here, we think about something like a speed limit. Or some value, which should not be exceeded (or exceedence leads to some consequence), or below which a measurement can't be quantified like a detection limit.

We would argue, that these kinds of limits do generally have an upper or lower meaning associated with them. So the use of schema:value can be and should be replaced with schema:minValue and/or schema:maxValue, to make the meaning of this limit clearer.

Edit: wrote schema:minInclusive which of course was rubbish, my bad. Replaced it with schema:minValue.

@Kronmar-Bafu I do not follow, which part is in your opinion missing from the spec? The snippet shows schema:limit but it also says that minValue/maxValue can be used.

meta/core.md

Rdataflow · 2024-10-15T13:50:33Z

validation/standalone-constraint-constraint.ttl

+            [
+                sh:property
+                    [
+                        sh:path [ sh:alternativePath ( schema:minValue schema:maxValue ) ] ;
+                        sh:minCount 1 ;
+                        sh:maxCount 2 ;
+                    ] ;
+            ]


@tpluscode IIUC this shacl will allow single upperLimit w/o lowerLimit, correct? 🤔 - which is what @Kronmar-Bafu expects 👍 in order to allow logical checks if values are exceeding the limit ... and style charts accordingly.

i.e. emission limits typically are of kind upperLimit - emssions are expected to stay below

Kronmar-Bafu

Clarification on our point about schema:value and its potential confusion

Kronmar-Bafu · 2024-10-28T14:27:41Z

meta/core.md

+  a cube:MeasureDimension ;
+  meta:annotation [
+    a meta:Limit ;
+    schema:value 95 ;


Here, this part, schema:value is too generic. Do we mean a lower or an upper limit?

We can avoid this confusion in at least three ways I could think of:

Introduce two new classes meta:UpperLimit and meta:LowerLimit

Add some other specification, like an additional meta:limitType "upper" or something like that

Be clear, on what we mean, by replacing schema:value by something more precise, like a schema:maxValue for an upper limit or a schema:minValue for a lower limit.

I would advocate together with Thomas for option three, as it reuses schema:maxValue/schema:minValue instead of introducing new things.

Ok, I think I understood now.

Let me clarify one more point. Would it ever make sense to have both schema:minValue and schema:maxValue on a limit. From what you write, I guess that is pointless?

Depends on how you want to look at it.

It could be, that something is supposed to follow an upper and a lower limit. One could then add a schema:minValue as well as a schema:maxValue to the same meta:Limit. Or be more precise and add two meta:Limit.

From a semantic's point it might be clearer to add two meta:Limit in such a case. So yes, there's not really a point to have both predicates for one meta:Limit. Or would you like to disagree @Rdataflow ?

I just imagined the case of a target range, being specified by means of lower and upper limit. Yes, for such cases it could make sense to have both at the some node ;-)

Two thoughts:

It could make sense to have min and max, together, so to allow multiple "limits" with corresponding upper and lower limit. (e.g. Target Band 2025, Target Band 2026) so I propose to keep connected min / max together.

It should be possible, to give a limit annotation a title, and probably also a sub-title/description. There might be multiple limit annotations, and earlier or later even a possibility to choose one, or multiple to show in an interface (e.g. visualize).

Alright, you got me conviced. I was steering more towards thinking of target ranges as "two limits in a trenchcoat" and thus wanting to split them up. But that would just be more "wordy". So let's keep the possibility.

As for your second thought @l00mi , I agree. a dcterms:title would make sense.

In principle, any property is allowed. The shapes aren't closed. Do you think it's worth mentioning that explicitly in the spec?

#206
@Kronmar-Bafu @Rdataflow

Kronmar-Bafu · 2024-10-28T14:29:55Z

validation/standalone-constraint-constraint.ttl

+                        sh:minCount 1 ;
+                        sh:maxCount 1 ;
+                    ] ;
+            ]


This sh:property could be removed if on decides on dropping schema:value in favor of schema:minValue/schema:maxValue.

tpluscode added 2 commits September 24, 2024 16:27

feat: annotations

641d841

chore: remove prefixes from examples

1010867

tpluscode requested review from semanticfire and giacomociti September 24, 2024 14:29

tpluscode commented Sep 24, 2024

View reviewed changes

meta/core.md Outdated Show resolved Hide resolved

refactor: values, properties, constraints

abfab69

giacomociti approved these changes Sep 27, 2024

View reviewed changes

test: valid annotations

400a1fb

tpluscode marked this pull request as ready for review September 27, 2024 08:05

chore: bnodes

160bdb2

giacomociti reviewed Sep 27, 2024

View reviewed changes

tpluscode added 2 commits September 27, 2024 10:16

revert: whitespace changes

58f152b

chore: remove unused shape

8dea9ea

tpluscode commented Sep 27, 2024

View reviewed changes

chore: bnodes

ab75afa

Base automatically changed from error-margin-validation to main September 30, 2024 10:17

Merge remote-tracking branch 'origin/main' into targets-limits

a3575ad

tpluscode merged commit a6ae0bc into main Oct 1, 2024
25 checks passed

tpluscode deleted the targets-limits branch October 1, 2024 07:49

Kronmar-Bafu reviewed Oct 8, 2024

View reviewed changes

Rdataflow reviewed Oct 15, 2024

View reviewed changes

Kronmar-Bafu reviewed Oct 28, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adds a feature of dimension anotations #202

Adds a feature of dimension anotations #202

tpluscode commented Sep 24, 2024

changeset-bot bot commented Sep 24, 2024 •

edited

Loading

giacomociti Sep 27, 2024

tpluscode Sep 27, 2024

giacomociti Sep 27, 2024

tpluscode Sep 27, 2024

tpluscode Sep 27, 2024

tpluscode Sep 27, 2024

tpluscode Sep 27, 2024

Kronmar-Bafu left a comment

Rdataflow Oct 15, 2024

Kronmar-Bafu Oct 22, 2024

Kronmar-Bafu Oct 24, 2024 •

edited

Loading

tpluscode Oct 28, 2024

Rdataflow Oct 15, 2024

Kronmar-Bafu left a comment

Kronmar-Bafu Oct 28, 2024

tpluscode Oct 28, 2024

Kronmar-Bafu Oct 28, 2024

Rdataflow Oct 28, 2024

l00mi Oct 29, 2024

Kronmar-Bafu Oct 29, 2024

tpluscode Oct 29, 2024

tpluscode Oct 29, 2024

Kronmar-Bafu Oct 28, 2024 •

edited

Loading

		In case of temporal dimensions, the constraint values are expected to be literals with datatypes `xsd:date`,
		`xsd:dateTime` or `xsd:gYear`, or the IRIs of [temporal entities](https://lindas.admin.ch/governance/core-entities/).


		</aside>

		`schema:minValue` and `schema:maxValue` can be used to express a range of limit values.

Adds a feature of dimension anotations #202

Adds a feature of dimension anotations #202

Conversation

tpluscode commented Sep 24, 2024

changeset-bot bot commented Sep 24, 2024 • edited Loading

🦋 Changeset detected

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kronmar-Bafu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kronmar-Bafu Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kronmar-Bafu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kronmar-Bafu Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

changeset-bot bot commented Sep 24, 2024 •

edited

Loading

Kronmar-Bafu Oct 24, 2024 •

edited

Loading

Kronmar-Bafu Oct 28, 2024 •

edited

Loading