Enable more Query Parameters for the AAS Registry

[sebbader]

Currently, GetAssetAdministrationShellDescriptorById only allows filtering for the id. More attributes, e.g. assetKind, can dramatically improve the search performance.

Open question: Shall all metamodel attributes be allowed? If so, is there still a difference between an AssetAdministrationShell and an AssetAdministrationShellDescriptor?

relates to finding BO#67.

duplicate of #16

[noheton]

Isn't this already in scope of the efforts in the TF Discovery (regarding query)?

[aorzelskiGH]

Let us briefly discuss a query language

[sebbader]

Argument against additional fields:

The Registry shall be a light-weight catalog of AAS identifiables. Giving them more attributes moves the registry closer to an AAS Repository, until the two concepts are not distinguishable anymore. Even further, the need for more expressive queries, as @noheton indicated, leads for me to a new AAS Query Service definition next to the Registry and Repository.

[BirgitBoss]

This is the Catena-X Requirement (restricted access: https://jira.catena-x.net/browse/A1SLDT-793):

Operation to be extended: https://semantics.int.demo.catena-x.net/registry/swagger-ui/index.html#/Registry%20and%20Discovery%20Interface/PostQueryAllAssetAdministrationShellIds

The /lookup/shells/query should support searches based on semanticId.

The search should allow OR and AND based lookups.

A type parameter should introduce to indicate which operation (OR/AND) should be used for the query.

{ "query": { "type": "and", "semanticIds": [ "com.catenax.Traceability", "com.catenax.AsPlanned" ] } }

The /lookup/shells/query supports already specificAssetId based searches. If the query object contains both query options assetIds and semanticIds the API should return a 400 Bad Request. We don't need to support both queries combined:

{ "query": { "type" : "and", "assetIds" : [ {
"key": "string", "value": "string" } ], "semanticIds" : [ "com.catenax.Traceability", "com.catenax.AsPlanned", ] } }

[BirgitBoss]

see also https://github.com/admin-shell-io/aasx-server/blob/master/examples/queries/Queries%20in%20AASX%20Server%20-%20Discussion%20Paper%20V0.2.pdf for prototype and proposal @aorzelskiGH

[aorzelskiGH]

The query discussion paper is now available as .md: https://github.com/admin-shell-io/aasx-server/blob/master/examples/queries/queries.md It is already implemented in AASX Server and working examples are provided in the document.

[danielporta]

I want to throw our AAS Registry & Discovery API extension regarding a lightweight search on descriptor contents in the ring. The OpenAPI definition can be found here. Although the following explanations refer to the AAS registry, they could as well be applied to the submodel registry.

A new /search endpoint receives a search request in terms of a JSON document. In that way the API can be stable if the descriptor schema(s) may change. Examples for search requests are:

• _Search for AAS with AAS-IdShort equals "mir100_1aas"

{ "query": { "path": "idShort", "queryType": "match", "value": "mir100_1_aas" } }

 - _Search for AAS with AAS-IdShort starts with "mir100"_

{ "query": { "path": "idShort", "queryType": "regex", "value": "mir100.*" } }

 - _Search for AAS that contain a submodel with a certain semanticId_

{ "query": { "path": "submodelDescriptors.semanticId.keys.value", "queryType": "match", "value": "https://wiki.eclipse.org/BaSyx_/_Submodels#Control_Component_Instance" } }

The `path` to the specified information in the `value` field uses a dot notation. The path segments correspond to the schema definition of AASDescriptor and SubmodelDescriptor. The information in the value field can be matched (`queryType`=`match`) as is or can be treated as a regular expression (`queryType`=`regex`)

Pagination and sort directions are also possible as the following example illustrates.

{ "page": { "index": 0, "size": 10 }, "query": { "path": "idShort", "queryType": "regex", "value": "mir100.*" } "sortBy": { "direction": "ASC", "path": [ "administration.revision" ] } }

The search result specifies the `total `number of found AAS Descriptors. The `hits` refer to the specified `page` in the initial request.

{ "total": 3, "hits": [

] } ```

[danielporta]

We introduced two query parameters assetKind and assetType in the GetAllAssetAdministrationShellDescriptors method as an intermediate step towards a more sophisticated query approach that may be realized as an additional POST method in V3.1.

[sebbader-sap]

https://app.swaggerhub.com/apis/Plattform_i40/RegistryServiceSpecification/V3.0#/Asset%20Administration%20Shell%20Registry%20API/GetAllAssetAdministrationShellDescriptors and https://github.com/admin-shell-io/aas-specs-api/blob/d6d8edff1445f6b74902e5dd5068783377a61c1f/RegistryServiceSpecification/V3.0.yaml#L45 should solve this issue:

@BirgitBoss can you please confirm that the current proposal for the V3.0 release is fine? Here also a screenshot from the document:

[sebbader-sap]

@danielporta please review and close the issue.

[BirgitBoss]

Instead of introducing more and more query parameter we should also (re)consider to introduce RQL-queries for the AAS and Submodel Registry.