Feature Collection caching + bugfix for CQL context

[recalcitrantsupplant]

• adds caching of Feature Collection query (the details of a feature collection are required to be included in the GeoJSON response for each page of a /items response, so the same Feature Collection query is called repeatedly. A 10 minute cache has been added with aiocache.
  • While caching may still be used in future, the query performance will be improved by converting the blank node selection blocks to equivalent UNION clauses.
• add JSON LD context back to the CQL queries. This is to work with the existing implementation of CQL -> SPARQL. As the test cases from OGC contained no URIs, a JSON LD context was applied to them to create URIs for testing against RDF. While this was helpful to have a reference set of test cases, it has caused other issues in parsing and would in hindsight be better left out.
• update the rdf2geojson version, the latest version addresses these bugs:

1. langStrings, my converter didn't detect a langstring as a string, so it treated it as a datatype literal, but there was no datatype, so it returned None.
2. Custom data types (like strings with source ID types etc) They now serialize to a nice little map with {"datatype": x, "value": y }
3. Numeric literals, there was a else statement that was supposed to treat eveything with a numeric datatype as a python object, to serialize out, but a bug prevented that from working, so numeric literals returned None.

[lalewis1]

Seems to work OK for me locally.

Should we include a statement in the ogc features readme, noting that these results may be cached?

I'll look into that failing ogc features test.

[recalcitrantsupplant]

Re caching yes... we should generally note in the documentation what things are cached, I think it's there for others, will update

[lalewis1]

thanks looks good :)

[github-actions]

🎉 This PR is included in version 4.2.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀