GeoSPARQL Standards Working Group Meeting Minutes
Meeting Details
Meeting Date: 11/08/2021
Meeting Time: 2030 UTC
Meeting Location: GoToMeeting
Attendees
Attendee |
Moniker |
Timo Homburg |
TH |
Matt Perry |
MP |
Frans Knibbe |
FK |
Nicholas Car |
NC |
Mathias Bonduel |
MB |
Note Takers
Action Items From Last Meetings
| Done? | Item | Responsible | Due Date |
| —- | —- | —- | — |
Discussion Items
Time |
Item |
Who |
Notes |
2036 |
Intro |
JA |
Call for PatentsRoll Call- Attendees recorded in minutes
- Attendees confirmed vocally
|
2044 |
Run through of Pull Requests |
JA |
- NC
- dcterms:isPartOf flipped to rdfs:member [#188](https://github.com/opengeospatial/ogc-geosparql/pull/188)
Small PR to change dcterms:isPartOf to rdfs:member - AusPIX removed from normative standing [#190](https://github.com/opengeospatial/ogc-geosparql/pull/190)
- SpatialMeasure props to use SpatialObject not Feature for domain [#184](https://github.com/opengeospatial/ogc-geosparql/pull/184)
- Domain of SpatialMeasure properties to be SpatialObject
- Internal IRIs [#186](https://github.com/opengeospatial/ogc-geosparql/pull/186)
- Convert IRIs in the spec to point to relevant sections of the spec document rather than the ontology
- The first hyperlink for the IRI (in the definition) still points to the ontology
- TH: Ok with link to the document, but we should keep the namespace reference in the link text for the IRI link
- NC: Flow of the text is better without the namespace
- NC: Will add back namespace for requirement text and leave namespace off of other references in text.
- NC: Will put PR back into draft until done making some changes.
- Relation of CQL to GeoSPARQL [#68](https://github.com/opengeospatial/ogc-geosparql/pull/68)
- TH: Ready for review. Can include in 1.1 or 1.2.
- NC: Ok to merge.
- Terms & Defs vocab [#165](https://github.com/opengeospatial/ogc-geosparql/pull/165)
- NC: Do we have enough terms for the glossary yet?
- FK: If we start with a core list, we can always add more later.
- NC: I thought we had some definitions written down somewhere.
- FK: I can look at that list and get it into shape.
- NC: I can find a few core Sem Web definitions to add too.
- FK: We can also check the normative references in Section 3
- NC and FK to work on this issue.
- adding a bunch of shapes [#173](https://github.com/opengeospatial/ogc-geosparql/pull/173)
- SHACL Shapes
- NC: Issue of regex-based shapes that look into geometry literals. Current GeoSPARQL spec doesn’t really deal with content of geometry literals - just refers to those geometry serialization specs.
- MB: Current thinking is just to make sure asWKT doesn’t point to geoJSON literal, for example.
- Could be expensive for large geometry literals.
- NC to take a closer look at the regex issue.
- [#177](https://github.com/opengeospatial/ogc-geosparql/issues/177)
- 1 serialization per geometry vs. multiple serializations per geometry
- Consensus to make multiple serializations a warning instead of a violation
- 2 serializations of the same type (e.g., 2 asWKT properties pointing to different literals) should be a violation
- MB to handle issue 177 updates.
- NC: if we close these remaining PRs we can vote within the GeoSPARQL SWG to move it forward to the OGC.
- NC: I can fix typos as I see them instead of creating new PRs.
|
2119 |
Other major issues? |
NC |
- FK: rename Spatial Measure [#103](https://github.com/opengeospatial/ogc-geosparql/issues/103)
- FK to put in a PR so that we can evaluate proposed change.
- MB: availability of vocabulary in JSON-LD
- NC: OGC NA will take care of this
- MB: what about publishing a JSON-LD context
- NC: Yes. This is sensible to do, and OGC NA does not do it.
- MB to create an issue for this.
- FK: Issue 60 missing license [#60](https://github.com/opengeospatial/ogc-geosparql/issues/60)
- NC: We will need to create a license in ORDL ourselves in the OGC namespace.
|
2129 |
Pull Request 136 |
JA |
PR #136 Update geo.ttl: redefine ontology terms for DGGS - FK: Is it valid to cast a DGGS object to a Geometry?
- NC: We are using DGGS literals the same way as geometry literals.
- FK: proposal is to define DGGS object as a subclass of SpatialObject
- NC: consequence is that topological functions for example need broader input types to handle this definition of DGGS object
- NC: we need to explore this further.
- FK: we can end up with some semantic contradictions if we define DGGS object as a Geometry
- NC: we need to add DGGS as a separate conformance class if it’s not already. NC to put an issue in.
|
2147 |
Any other issues? |
NC |
None |
2148 |
|
|
MEETING ENDS |
Action Items
| # | Item | Responsible | Due Date |
| —- | —- | —- | —- |