SupplementalSemanticIds in AAS Queries#568
SupplementalSemanticIds in AAS Queries#568sebbader-sap wants to merge 8 commits intoIDTA-01002-3-2_workingfrom
Conversation
|
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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
I think the seoncd [] on keys[] should remain keys[0] because then it is already a single semanticId
BirgitBoss
left a comment
There was a problem hiding this comment.
typo for supplemantal + question how we should deal with lists and abbreviated writing $eq
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>
|
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? |
|
And still the problem with the JSON Schema regex pattern exists... |
We decided to do it as defined in #568 (comment) |
| <EndpointClause> ::= "interface" | "protocolinformation.href" | ||
| <ReferenceClause> ::= ( "type" | "keys" ( "[" ( [0-9]* ) "]" ) ( ".type" | ".value" ) ) | ||
| <SemanticIdClause> ::= ( "semanticId" | "semanticId." <ReferenceClause> ) | ||
| <SupplementalSemanticIdClause> ::= ( "supplementalSemanticIds" | "supplementalSemanticIds" ( "[" ( [0-9]* ) "]" ) "." <ReferenceClause> ) |
There was a problem hiding this comment.
The shorthand .supplementalSemanticIds refers to .supplementalSemanticIds[].keys[0].value.
Unlike .semanticId, this field is an array, which introduces additional complexity in the shorthand.
To stay consistent with .semanticId, we should explicitly indicate the array nature, e.g.:
.supplementalSemanticIds[], or
.supplementalSemanticIds[index]
If we choose to use .supplementalSemanticIds as a shorthand, we must clearly document that it represents .supplementalSemanticIds[].keys[0].value.
Closes #524