Query data using SPARQL from Cumulocity

vachaspati_Diwevedi1 · August 22, 2022, 7:56am

What product/components do you use and which version/fix level are you on?

Cumulocity 10.6

Is your question related to the free trail, or to a production (customer) instance?

POC

What are you trying to achieve? Please describe in detail.

Devices are populating data to Cumulocity, Customer wants to use SPARQL Query (Brick Schema) to fetch the data from Cumulocity. Is to feasible to write any query abstraction layer (microservice) to

parse the SPARQL query
fetch data from Cumulocity using REST APIs
build & send the response as JSON?

or should we think of using any other approach like

Query Cumulocity data
Transform into Graph dataset or RDF node format and store in another DB
Apply SPARQL query on the dataset & fetch the data

Any information or hint would be helpful

Do you get any error messages? Please provide a full error message screenshot and log file.

Have you installed all the latest fixes of the products and systems you are using?

yes

Michael_Cammert · August 23, 2022, 5:10pm

Hi!

As you are still in the PoC phase, I would recommend to move to a newer version of Cumulocity IoT if possible.

If I get SPARQL right, using d2r-query it can run queries against relational databases via JDBC? If this is correct, you might want to take a look at Cumulocity IoT DataHub which allows you to access data offloaded from the Cumulocity platform via JDBC: Cumulocity IoT DataHub overview - Cumulocity IoT Guides

Regards,
Michael Cammert

vachaspati_Diwevedi1 · August 24, 2022, 5:42am

Hi Michael,

Thanks for sharing the information.
If I understand correctly using this approach d2r-query & IoT Datahub, only offloaded data will be queried via JDBC?

Michael_Cammert · August 24, 2022, 4:18pm

Hi!

Yes, in general this would only query data which has already been offloaded, so not cover the data from the latest hour. We were already able to remove that restriction for a special case and hope to be able to do this for other cases as well in future versions.

However, from our exprience for many analytic queries this restriction is totally acceptable. Keep in mind that on the pro side at first sight (I did neither investigate this in detail nor try it) this approach would allow for your use case without the need for any custom implementation.