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