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