Skip to content

SupplementalSemanticIds in AAS Queries#568

Draft
sebbader-sap wants to merge 5 commits intoIDTA-01002-3-2_workingfrom
SeBa/524-SupplementalSemanticIds-in-queries
Draft

SupplementalSemanticIds in AAS Queries#568
sebbader-sap wants to merge 5 commits intoIDTA-01002-3-2_workingfrom
SeBa/524-SupplementalSemanticIds-in-queries

Conversation

@sebbader-sap
Copy link
Copy Markdown
Contributor

Closes #524

@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Mar 29, 2026

CLA assistant check
All committers have signed the CLA.

@sebbader-sap sebbader-sap changed the base branch from main to IDTA-01002-3-2_working March 29, 2026 16:41
@sebbader-sap
Copy link
Copy Markdown
Contributor Author

I am not able to provide a proper JSON Schema pattern. Any help is highly appreciated.

This shall also work for supplementalSemanticIds, e.g.:

....
$sme#supplementalSemanticIds $eq "https://example.com/a/supplemental/semantic/id"
Copy link
Copy Markdown
Collaborator

@BirgitBoss BirgitBoss Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it could be
$sme#supplementalSemanticIds $contains "https://example.com/a/supplemental/semantic/id"
since it is a set

$contains is for comparing two string... but so far we do not have set-operations, do we?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least I am not aware... Some query languages have an $in operator. But it then would need to have a different order:
"https://example.com/a/supplemental/semantic/id" $in $sme#supplementalSemanticIds
Also pretty big change.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it was clever to keep it close to $sme#semanticId. Not sure if it really is.


Which is equivilant to:
....
$sme#supplementalSemanticIds[0].keys[0].value $eq "https://example.com/a/supplemental/semantic/id"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then with "contains" it would be

$sme#supplementalSemanticIds[0].keys[0].value $eq "https://example.com/a/supplemental/semantic/id" OR $sme#supplementalSemanticIds[1].keys[0].value $eq "https://example.com/a/supplemental/semantic/id" OR $sme#supplementalSemanticIds[2].keys[0].value $eq "https://example.com/a/supplemental/semantic/id" a.s.o.

In general: how do we know what is the highest number in a list and how long to iterate?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general: how do we know what is the highest number in a list and how long to iterate?

Currently: Not at all. But no index indicates "anywhere", so this might work better:
$sme#supplementalSemanticIds[].keys[].value $eq "https://example.com/a/supplemental/semantic/id"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the seoncd [] on keys[] should remain keys[0] because then it is already a single semanticId

Copy link
Copy Markdown
Collaborator

@BirgitBoss BirgitBoss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo for supplemantal + question how we should deal with lists and abbreviated writing $eq

sebbader-sap and others added 3 commits March 30, 2026 17:42
Co-authored-by: Birgit Boss <59824205+BirgitBoss@users.noreply.github.com>
Co-authored-by: Birgit Boss <59824205+BirgitBoss@users.noreply.github.com>
Co-authored-by: Birgit Boss <59824205+BirgitBoss@users.noreply.github.com>
@sebbader-sap
Copy link
Copy Markdown
Contributor Author

Thanks @BirgitBoss ! I have addressed the typos. I have only an idea for the abbreviation clause, not really a bullet-proof approach. Would it be feasible to drop it for now?

@sebbader-sap
Copy link
Copy Markdown
Contributor Author

And still the problem with the JSON Schema regex pattern exists...


Which is equivilant to:
....
$sme#supplementalSemanticIds[0].keys[0].value $eq "https://example.com/a/supplemental/semantic/id"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
$sme#supplementalSemanticIds[0].keys[0].value $eq "https://example.com/a/supplemental/semantic/id"
$sme#supplementalSemanticIds[].keys[0].value $eq "https://example.com/a/supplemental/semantic/id"

To ease writing, `.keys[0].value` can be left off for References. +

semanticId is defined as the "value" of the first key of the semanticId Reference object.
The following two expressions are equivilant:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The following two expressions are equivalent:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Extend Query Language for supplementalSemanticId

4 participants