search

opengeospatial / ogcapi-features

An open standard for querying geospatial information on the web.
https://ogcapi.ogc.org/features
Other
342 stars 85 forks source link

Common Query Language (CQL) extension available for review #367

Open pvretano opened 4 years ago

pvretano commented 4 years ago

Dear Colleagues,

The purpose of this message is to announce that preliminary drafts of the following documents are now available on github:

OGC API - Features - Part 3: Common Query Language (http://docs.opengeospatial.org/DRAFTS/19-079.html

The Common Query Language extension defines a richer filter expression language than is currently defined for "OGC API - Feature - Part 1: Core". Part one defines three filtering parameters: bbox, datetime and equality filtering on feature properties. CQL defines logical, comparison, temporal, spatial and other operators that allow clients to create richer filtering expressions for retrieving features from a collection.

The OGC API - Feature SWG is requesting that interested parties review the document, provide feedback via the github issue tracker and most importantly implement!

Thanks you for your consideration.

Ciao.

akuckartz commented 4 years ago

What about support for SPARQL ?

rob-metalinkage commented 4 years ago

Possibly GraphQL is more important than SPARQL - simpler to use and more widespread - but handles graph data models too.

cholmes commented 4 years ago

Wouldn't those both just be their own extension? Why would they go into the CQL extension? I'd love to see a GraphQL query language as an option, I think @sharkinsspatial did this with a @developmentseed STAC server, as an alternate filter language but still using the rest of the stac/features api mechanics.

rob-metalinkage commented 4 years ago

Let me amend me suggestion to use GraphQL - thats just a pointer to evidence that there are other "shapes" oriented languages out there.

From a standards perspective, to be forward looking we should probably focus on profiles for SPARQL, SPARQL* and GQL [1]

The main point is that we recognise the API needs to have a option to navigate graph databases - and the real design issue is whether you have a generic language or one mediated by a discoverable "shape" - and where the metadata needed to drive either approach is canonically available in the API.

There are three tiers of options - which all just push the inherent complexity around different responsible agents: 1) generic query with ability to discover schema (SQL never standardised the discovery part) - SQL, SPARQL, etc. Then for a relational object client can work out what may be joined where keys are declared, but needs to use external documentation or trial and error to work out which parts of the discovered schema are actually populated with what values before a valid query can be issued.

2) Frame(shape, schema, pattern etc) where joins are predetermined and valid query paths declared - GQL (patterns), GraphQL, XSD+ XQuery etc. Client still has no canonical means of discovering valid values, and must use data inspection or external documentation

3) A graph mode including a canonical model for describe data values (e.g. RDF Datacube for dimensional shapes). This extends the first two options and leaves less responsibility to the client to resolve 90% of the interoperability problem without any standards.

In a nutshell +1 to supporting graph models and query languages - but I suggest you base it on a conceptual model whereby it is possible to specify what form the semantic metadata is attached to the graph. No existing solution is perfect or well known yet, so profiles of the conceptual model need to be easy to generate for emerging options. Therefore the IMHO the single greatest imperative is to respect the core+profile model and make sure implementations are treated as profiles - and these can be refined. e.g. a GQL profile can be refined with a GQL+RDF-QB metadata option for data that fits that sort of pattern.

[1] https://www.gqlstandards.org/

cportele commented 4 years ago

Meeting 2020-07-06: Planned timeline is:

cportele commented 3 years ago

The public review of Part 3 is until 2021-04-19.

See https://www.ogc.org/standards/requests/229

cportele commented 3 years ago

@ogcscotts @ghobona @pvretano

There has been a discussion on Gitter to extend the public review to allow more implementation feedback. In ldproxy we are still updating the server code to the changes and probably will finish in-time for the mid April target, but to get client implementation feedback there should be at least two servers that implement the draft and that the clients can use for testing and they can only really start once the servers are ready. So, I propose that we extend the comment period by, say, another two months. Our approach has always been to have a longer period than the regular 30 days to allow more time for implementation feedback (it was almost 6 months for Part 1) and if we know that we will get this by extending the period, we should do it.

We could extend the public review officially (OGC announces the extension) or inofficially (we simply announce it here and on Gitter and just wait until we think we have sufficient implementation feedback).

Going forward, maybe we should consider a "SWG policy" that we only go to public comment, if we have at least two servers that implement a draft? In fact, that might even be a good guidance for all the OGC API candidate standards.

Any thoughts?

cc @cholmes

pvretano commented 3 years ago

Situation is pretty much the same for CubeWerx; should have a complete implementation of Part 3 in the next few weeks. Filter works (example) but there are lots of bits and pieces that need to be polished up. I agree with @cportele about having at least 2 server implementations available for client testing. We, CubeWerx I mean, have been working on an OGC API Client and that different perspective reveals quite a few areas where clarifications might be required.

ogcscotts commented 3 years ago

@cportele @pvretano @ghobona No problem extending the comment period, but let's do it via GitHub and Gitter as we already have so much official communication through OGC and will have a bunch right now after the Member Meeting that this message may just get lost. Many SWGs take public comments well past the deadlines anyhow.

If the SWG wants to set its own policy for waiting on public comment until it knows of two server instances, that is fine. Other OGC API SWGs could adopt similar rules if they want.

cportele commented 3 years ago

Sounds good. Let's discuss the details in the next SWG call on 12 April.

cholmes commented 3 years ago

Sounds great. And going into comment period with at least two publicly accessible servers seems like a good idea.

Is it normal to cut new drafts during the comment period? The comment period feels like what we're calling 'release candidates' in STAC, and it's nice to be able to fully cut a new release so that tooling can explicitly refer to that version.

cportele commented 3 years ago

@cholmes - Yes, we have started to tag the versions for the public review, which we also consider release candidates. For example, the public review version for Part 3 is 1.0.0-draft.2: https://github.com/opengeospatial/ogcapi-features/releases/tag/part3-1.0.0-draft.2.

cportele commented 3 years ago

Meeting 2021-04-12: