GeoSPARQL Standards Working Group Meeting Minutes

Meeting Details

Meeting Date: 18/11/2020

Meeting Time: 2030 UTC

Meeting Location: GoToMeeting

Attendees

Attendee Moniker
Dimitris Kotzinos DK
Frans Knibbe FK
Gabriella Wiersma GW
Joseph Abhayaratna JA
Josh Lieberman JL
Krzysztof Janowicz KJ
Matthew Perry MP
Nicholas Car NC
Paul Cripps PC
Simon Cox SC
Timo Homburg TH

Note Takers

  • JA
  • KJ

Discussion Items

Time Item Who Notes
2030 Intro JA Call for Patents
- None known
Roll Call
- Attendees recorded in minutes
2040 Protocols All - Minutes will be taken in Google Doc, and translated to Github meetings log
- Setup: pull requests will be checked by two other members of the group
Reviewing 1.1 pull requests.
2050 Issues and Pull Requests All Closing issue https://github.com/opengeospatial/ogc-geosparql/issues/50
Merging pull request https://github.com/opengeospatial/ogc-geosparql/pull/53
2100 Issue #10 Also relates to https://github.com/opengeospatial/ogc-geosparql/issues/15  
2110 Scope - Making all definitions e.g., for Geometry, Web-available in Semantic Web Format / RDF
- SC: All we are discussing for now are annotation properties that do not affect semantics
- Discussion on whether the 1.0 ontology should be changed at all no matter whether it will chains any entailments.
- Agreement: All the changes will be made to 1.1, not 1.0.
 
2120 GeoJSON https://github.com/opengeospatial/ogc-geosparql/issues/48 NC - Discussion on how to deal with geo:hasSerialization and more specific serializations such as GeoJSON.
- KJ/NC/SC on the need for URIs for Geometries etc
- MP: There are useful use cases for serialization specific relationships such as asWKT.
Agreement: #48 can be approved
2130 Representing empty literals TH - Are we restricting us to WGS84 → the format does this, not us.
- JL: This would have to be a flavor of JSON that does not conform to GeoJSON
- SC: GeoJSON is unlikely to change and one would need another serialization and there even may be naming issues
- JL: There are many reasons to have a GeoSPARQL-JSON
- TH: do we need something like ‘empty’ points? Instead of a NULL geometry
- NC → POINT() but (TH) how does this differ from the entirely empty literal?
- Two class hierarchies, why?
- SC: As far as OGC is concerned all roads lead to https://www.iso.org/standard/66175.html Does are not Web-ready so to speak
2150 Other Business All Do we want to allow for external artifacts? At last not those that would create logical inconsistencies depending on the formalism we use.

Action Items

None