opengeospatial / geosemantics-dwg Goto Github PK

The URI http://www.data-intelligence-journal.org/p/24/#Ch-S2 in the White Paper's references doc is broken.

Hi all,

I just wanted to point to work done by the CIDOC-CRM people. This group made a Concept Reference Model (CRM) or ontology for cultural heritage management which is since 2006 an ISO standard. As far as I could derive from literature and their website, they mainly use text reports and formalized schemas in RDF serializations and 'plain' XML.

This group also host numerous extensions to the 'base' CRM model, including one named CRMgeo oriented at spatiotemporal concepts that extends concepts of GeoSPARQL. I think the most recent version of CRMgeo is 1.4, but I could not find a confirmation on the official CIDOC-CRM page.

It might be relevant to go through the CRMgeo proposal, as it probably contains extensions or concepts that are relevant for other application domains working with spatiotemporal data. Maybe we can ask some of the developers to contribute to this white paper (use cases and/or proposals for extensions)?

Potential relevant sources:

• official CIDOC-CMR webpage with links to CRMgeo v1.2 documents (.pdf/.doc and .rdf)
• erlangen-owl version of CRMgeo v1.4
• scientific paper describing CRMgeo (open access)

This issue covers some of the discussion in the gitter channel of the sprint

The typical use case raised by the jena team is an ability to convert spatial data to rdf using a tool like qgis or geoserver and push it to fuseki. They currently use an approach with CSV containing wkt.

An alternative would be the use of GeoJSON-ld. GeoJSON-ld has long struggled with a limitation in json-ld to have exted arrays. This limitation has been resolved in json-ld spec 1.1, however from the documentation it is not clear if current jena support the 1.0 or 1.1 json-ld specification. My impression is that 1.1 is not supported.

GeoJSON-ld is a very likely encoding of OGC API Features & Records output, some implementations are already available, for example at https://demo.pygeoapi.io/master/collections/lakes/items?f=jsonld

An alternative approach here is to use SPARQL to query an OGC API Features endpoint (in case it supports json-ld).
You can use the ARQ tool which is included in the jena-release to query a json-ld document (and all documents linked from that document). This case brings in some suggestions to a JSON-ld output encoding of OGC API's, this case would benefit from bidirectional links between collections and items.

Many of the Use Cases mention the Optique platform and use the acronym VKG, which I've not hear before, so it's obvious that they have all been source from one similar place. I suggest some of them are replaced with different Use Cases and different approaches/tools.

No reference is provided for the Constitute Project on White Paper clause 2.

Dear WG,

I am supporting SEMIC as editor for the DCAT profiles. I heard that OGC is willing to invest in an update on GeoDCAT-AP.
I reach out to streamline this activity.

kr,

Bert

The White Paper, clause 2 cites [53, 54, 55, 56, 57, 59, 61, 63, 65] but there are no reference with those IDs given that I could find.

I assume these come from the non-resolving reference [3]?

GeoSPARQL combines both the graph structure and location referencing, so potentially it could be useful for assisting Contact Tracing in COVID-19 response (or in response to any outbreak).

Perhaps also make reference to the Health SDI White Paper http://docs.opengeospatial.org/wp/19-076.html