[FeatureRequest] Support RQL-queries for the AAS and Submodel Registry APIs

[BirgitBoss]

What is missing?

As requested in #7 and #169 and probably more additional querying is needed.

How should it be fixed?

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

Adding RQL would be backward compatible and does not lead to an explosion of API operations.

• I have signed the required Developer Certificate of Origin (DCO) already.

[kenwenzel]

@BirgitBoss Do you mean this query language:
https://github.com/a8m/rql

A very simple query language is also used by OSLC:
https://docs.oasis-open-projects.org/oslc-op/query/v3.0/oslc-query.html

OSLC query is very restricted and it should be simple to implement it in different languages.

[arnoweiss]

@BirgitBoss Can you provide a little more context on what "RQL" is? It's hard to conceptualize otherwise.

[BirgitBoss]

it is https://github.com/persvr/rql

[waltersve]

Regarding the OSLC specification, its primary intent is to query RDF resources, which isn't the case for the Registry. In terms of simplicity, one could argue that RQL is easier to read and understand, although this may vary based on individual preferences. However, it's worth noting that using RQL typically requires less code for the same query compared to OSLC and their is not so much support on up-to-date libraries for different languages. It seems also that RQL is more used by different companies e.g CludBlue, Extra Horizon, Rollbar, ...

[kenwenzel]

@waltersve Thank you for looking into OSLC query. Yes, it is primarily intented to query RDF as OSLC data integration is also based on RDF.
However, I would challenge your points regarding the compactness of OSLC queries vs. RQL. Also OSLC queries are very restricted and hence easier to implement. The whole grammar of oslc.where is as follows:

    oslc_where    ::= "oslc.where=" compound_term
    compound_term ::= simple_term (space? boolean_op space? simple_term)*
    simple_term   ::= term | scoped_term
    space         ::= " " /* a space character */
    boolean_op    ::= "and"
    term          ::= identifier_wc comparison_op value | identifier_wc space in_op space? in_val
    scoped_term   ::= identifier_wc "{" compound_term "}"
    identifier_wc ::= identifier | wildcard
    identifier    ::= PrefixedName
    PrefixedName  ::= /* see "SPARQL Query Language for RDF", http://www.w3.org/TR/rdf-sparql-query/#rPrefixedName */
    wildcard      ::= "*"
    comparison_op ::= "=" | "!=" | "<" | ">" | "<=" | ">="
    in_op         ::= "in"
    in_val        ::= "[" value ("," value)* "]"
    value         ::= uri_ref_esc | PrefixedName | literal_value
    uri_ref_esc   ::= /* an angle bracket-delimited URI reference in which > and \ are \-escaped. */
    literal_value ::= boolean | decimal | string_esc (LANGTAG | ("^^" PrefixedName))?
    boolean       ::= "true" | "false"
    decimal       ::= /* see "XML Schema Part 2: Datatypes Second Edition", http://www.w3.org/TR/xmlschema-2/ */
    string_esc    ::= /* a string enclosed in double quotes, with certain characters escaped. See below. */
    LANGTAG       ::= /* see "SPARQL Query Language for RDF", http://www.w3.org/TR/rdf-sparql-query/#rLANGTAG */

I've found some RQL examples on Bosch's documentation for querying the digital twin registry:
https://docs.bosch-semantic-stack.com/registry/find-digital-twins.html

RQL	OSLC query	Description
(twinCategory,"Machine","Device")	twinCategory in ["Machine", "Device"]	All digital twins that have a twinCategory of either "Machine" or "Device"
and(eq(twinCategory,"Printer"), eq(labels.name,"Floor1"))	twinCategory = "Printer" and labels { name = "Floor1" }	All digital twins with given twinCategory and at least one label with name Floor1
eq(digitalTwin.aspects.modelReference.urn, "urn:samm:com.bosch.nexeed.digitaltwin:aspect-model:Aspect:1.1.0")	digitalTwin { aspects { modelReference = <urn:samm:com.bosch.nexeed.digitaltwin:aspect-model:Aspect:1.1.0> } } }	Twin with specific aspect model.

The main difference is that OSLC query is based on nested properties of an object while RQL uses the usual object-oriented path syntax to reference related objects.

I'm not against using RQL. I just want to show that there are other options that may also be worth investigating.

[waltersve]

@kenwenzel It is right that OSLC queries could be compact as well. In case of RQL one difference would be that the query must not be encoded and can be used also as query parameter (where I also would recommend to use a POST request to avoid any issues e.g. URL is too long). It seems also that for OSLC ist not widely adopted and mainly used in dedicated areas where SPARQL and RDF plays also a role. In contrast, RQL (Resource Query Language) is designed specifically for RESTful resources, providing a more straightforward approach to querying REST-based systems. For me there is currently no universal query language standard for REST APIs, and I don't expect one to emerge in the foreseeable future. My primary decision factors are simplicity and commonality. In this context, RQL operator like eq or not etc. are similar to for example the once with are used in GraphQL or Google APIs which helps developer to get started. Also not defining additional topics like PrefixedName which could be misleading.