Information model query

Having an information model is one thing. Querying to extract data is another.

As an RDF Graph knowledge base the information model can be directly queried using SPARQL via the information model SPARQL end point.

However, as Health records are likely to be stored as relational, or at least SQL compatible data bases, querying health records that are aligned with the model will require SQL to query it.

Exposing general query languages via APIS such as SPARQL end points brings problems because of the extensive nature of those languages. It is hard to prevent highly damaging queries being run. The general approach is to put time outs on the query or balance queries.

The gap between plain language query and SQL or SPARQL is large and direct mappings between one and the other have not proved successful in the market place. It is unlikely that most users will be able to build complex queries directly in either SQL or SPARQL.

Furthermore, these languages provide result sets are provided in their native form which requires software to process and map to the client formats

To address this problem, Query applications use various domain specific languages to bridge from user friendly screens to the lower level languages that actually retrieve or update data. These languages support the actual requirements of the applications, for example Power BI uses DAX and M.

There have been attempts at bridging some of the gaps. The Facebook language GraphQL is designed to provide results sets in the form requested, but GraphQL does not support standard query functions such as filter, without extension and the use of method parameters, which in effect is another programming language.

The information model languages includes a "bridging language"

The information model has three main categories of use case that require such a bridge:

1. Query of the information model content by end users e.g. finding concept
2. Query by the information model applications via the IM APIs to retrieve objects for display or update the stored objects
3. Query by health staff of implemented health records , using a plain language or graphical query builder.

The approach taken by information model is to provide, as an option to raw SPARQL, a pragmatic intermediate query object model that supports all 3 categories. This model is then used by the applications themselves but is also available for use by third parties via the APIs.

The query model is designed meets the following requirements:

1. Should be easy to map to and from plain language
2. Should be easy to map to and from a SQL or SPARQL query with a JSON response object builder.
3. Should return the result set in the form that the client has described in its request. e,g. nested JSON or CSV.
4. Should use request format in JSON format.
5. Should support the IRI format of the IM content.

The following are not requirements

1. To operate as a fully functional query language

Grammar

This is the section on grammar