GeoSPARQL Standards Working Group Meeting Minutes

Meeting Details

Meeting Date: 11/03/2021

Meeting Time: 2030 UTC

Meeting Location: GoToMeeting

Attendees

Attendee Moniker
Joseph Abhayaratna JA
Gabriela Wiersma GW
Timo Homburg TH
Nicholas Car NC
Frans Knibbe FK
Matthias Bonduel MB
Matthew Perry MP
Krzysztof Janowicz KJ
Peter Vretanos PV
Robert Gibb RG

Note Takers

  • KJ
  • JA

Action Items From Last Meetings

Done? Item Responsible Due Date
Y NC takes care of mistakes in ASCIIDoc Conversion and missing images. Documentation should be discussed altogether at the end NC Next Meeting
Y NC proposes a fix for the DGGS Literal NC Next Meeting
Y TH leads efforts to define SQL/CQL to GeoSPARQL mappings as annex to GeoSPARQL TH -
Y NC to put a pull request NC Next meeting
Y NC to send a note to implementers NC Next meeting
Y Get volunteers for translation, NC to add a note NC Next meeting

Discussion Items

Time Item Who Notes
2033 Intro JA Call for Patents
  • None known
Roll Call
  • Attendees recorded in minutes
  • Attendees confirmed vocally

GeoLD Paper NC
  • Nick is looking to get a conference paper together for GeoLOD (https://dice-group.github.io/GeoLD2021/) as a way of advertising the new edition of GeoSPARQL to a relevant community
  • He’s hoping to cover off on the new things being added to GeoSPARQL 1.1.
  • Paper is due 15th March 2021
  • Keen to summarise the additions and provide some background on why those things have been added, drawn from the white paper, recent OGC testbeds, etc.

Issues without milestone FK
  • There have been a number of new issues added since we started working on the standard, which have not been assigned a Milestone (e.g., GeoSPARQL 11)[(**Action 1**)](#action_1)

GeoSPARQL Implementations NC Implementation of the standards
  • Combine emergency data information, e.g., on wildfires. This will include harmonization. We (NC+SC) use GeoSPARQL version 1.1.. Mix of standards including DGGS and GeoJSON. Need to prepare spatial querying functions for these literal types
  • Python GeoSPARQL: https://github.com/RDFLib/rdflib-geosparql/
  • Will include work as part of the Jena framework that now also supports GeoSPARQL.
  • Five people working on this full-time. We will have a public endpoint for the emergency data very soon.
  • In addition to an endpoint, there will also be a Linked Data API.
  • Time variance will be the next big step, e.g., for GeoSPARQL 2.0
  • MB: Strabon paper st-sparql including temporality for wildfires in Greece: http://link.springer.com/10.1007/978-3-642-35176-1_19 and https://www.sciencedirect.com/science/article/abs/pii/S1570826814000031
  • NC: use OWL Time. Allan interval algebra could be integrated to support temporal functions.
  • RG: merge owl-time with spatial operations
  • KJ: Spatial and temporal scoping may also be of interest to GeoSPARQL 2.0
  • NC: Temporal reference systems
  • FK: What about discrete global grid systems? There are already tickets, which have been completed, that explore DGGS Literals.
  • MB: already ticket for adapting getSRID function to SRS terminology?
  • RG: RSID as a combination of spatial and temporal RS IDs.
  • TH: need for SPARQL extension function to transform geometry between two SRS?
  • NC: function to transform between geometry serializations?
  • TH: generic function versus many different pair-wise functions.
  • Two issues SRS transformation and serialization transformation [(**Action 2**)](#action_2)

GeoSPARQL Compliance Benchmark TH Presentation of GeoSPARQL benchmark: what and when? Nothing new to report.
2117 Review of new issues JA
  • Comments on issues of 1.1 versus 2.0
  • NC, KJ, JA: discussion on issue #83 on spatial measures.
  • NC we need to push a bit deeper beyond simple comment to address this.
  • NC should be 1.1
    - Rename SpatialMeasure [#103](https://github.com/opengeospatial/ogc-geosparql/issues/103)
  • KJ Metrically defined topological relations → Egenhofer and Celementini and others have shown for years the need for going beyond crisp RC8 relations and they may be worth investigating at some stage. Maybe 1.2
  • FK: [#43](https://github.com/opengeospatial/ogc-geosparql/issues/43) multi-language support → content negotiation
  • PI Yes to content negotiation
  • NC, JA, KJ: how to support different languages in the GeoSPARQL ontology.
  • NC: just annotations so far. There is more here and a lot of research would have to go into this.
  • MB: To keep in sync only update other languages than English after milestones.
  • RG: Are there any parallels with the TC211 multi-lingual glossary of Terms and the supporting software geolexica? cf https://www.isotc211.org/ for lunks to both
  • NC +JA: Do it for 1.1
  • KJ to do Polish and German
  • FK: to do Dutch
  • GW: to do Portuguese
  • FK: [#42](https://github.com/opengeospatial/ogc-geosparql/issues/42) → moved to discovery and 1.2 or 2.0
  • MB+JA: How do we deal with RDF* and SPARQL* → moved to questions
  • More on geometries and their representation beyond literals → 2.0
  • MB [#26](https://github.com/opengeospatial/ogc-geosparql/issues/26) FK widen applications beyond geographic data (3D, any geometry format, binary formats). Might need to implement a restriction to max 1 serialisation per geometry instance (breaking change) for adding metadata (SRS, number of vertices, etc.) regarding the geometry serialisation. -> 2.0

OGC API - Features - Part 5: Search PV
  • https://github.com/opengeospatial/ogcapi-features/tree/master/proposals/search
  • MB asks about relations to grlc: https://github.com/CLARIAH/grlc => more focused on SPARQL only while OGC API is broader (SQL, CQL, SPARQL, etc)
2207     MEETING ENDS

Action Items

# Item Responsible Due Date
1 JA to add a standing item to the agenda to review the new issues and assign a milestone JA Next Meeting
2 FK to create issues for SRS transformation and serialisation transformation FK Next Meeting