Re: [sdw] Analysis gaps (#1259)

My first quick analysis

**[13.1] identifies gaps concerning the sharing of geometries on the Web**. It describes 3 concerns: 
1. We could not find one single way to express geometries that is recommendable in all cases. To my knowledge this is still the case, but I'm not sure I consider that a 'gap'. There are simply different recommendable ways of doing it for different use cases. We describe that in BP4. We might be able to improve on the text in that BP based on new insights. 
2. We couldn't identify a best practice for publishing geometries of different precision and accuracy. I think that is still the case. I don't know of new practice that adresses this. 
3. We couldn't identify a best practice for publishing and accessing geometries in different CRS. Here, I see a practice emerging. There are new developments, such as a standardized way to deal with this in OGC API Features (already published standard), GeoSPARQL 1.1 (on the way). 
   We described a possible way forward with CRS conneg, but I haven't seen that gaining traction. It is only implemented in the Netherlands. Perhaps we should consider removing it. 

**[13.2] identifies the lack of a go-to spatial data vocabulary**. GeoSPARQL is mentioned there; my first thought is that GeoSPARQL 1.1, which is being developed now, might fill that gap. Its vocabulary is richer than it was in 1.0 and includes some useful properties like centroid and bounding box, to mention a few. 
Of course, it's too early to proclaim this a best practice on the basis of GeoSPARQL 1.1, because it will not be a standard for a while yet, let alone an implemented one for which we can find good practice in the wild. 

**[13.3] identifies a gap in standardized dataset and service descriptions for data portals**. It mentions the OGC working on such a standard, but to my knowledge no such work is progressing at the moment. Maybe we were thinking of GeoDCAT-AP, a European standard; there were plans for picking that up within OGC but I think it has stalled. 
Meanwhile, there is a new version of GeoDCAT-AP based on DCAT 2.0. Even though it is not a worldwide standard, we might say, well there is a good practice we see in the wild in Europe, let's promote this to a BP. That's one way forward. 

We also know DCAT 2.0 on its own is already better equiped for describing geospatial datasets and for describing data services. We're already feeding that into the BP thanks to Andrea. 

The question is, is DCAT 2.0 enough or do we consider there to be a gap until something like GeoDCAT-AP is established in practice.

**[13.4] is about dynamic and large datasets**, specifically spatio-temporal ones that you want to expose subsets of because they're so large. QB4ST is mentioned as a possible solution. At the time this was new and not used in practice, only in research settings. I have no it being applied in practice now, but others might know of this? 

Another possible approach to publishing large dynamic datasets that is emerging now might be EDR. Probably also too new to be called a best practice, yet. But we could mention it in addition to QB4ST. I'm curious to hear the groups opinion on this. 

**[13.5] identifies a gap concerning units of measure**. Actually the text in this Gap section is sensible, it contains sound advice, boiling down to: if your data has measures be explicit about the unit of measure; include it either as a literal (in that case use UCUM) or as a URI (in that case several collections to choose from). At the time we said there was no evidence of best practice for this advice. This practice might have emerged since then; in that case we could convert this into a best practice. One place we might look for emerging practice is in the Web of Things work (our Gap section mentions they were planning to work on this topic). 

One problem is, there is still no single definitive collection of units of measures  one could point to. There's UCUM, QUDT, the Ontology of units of measure... In our best practice 4 about encodings for geometries we don't have one single encoding we recommend, either, so this need not stop us making this a best practice, if we see enough evidence in the wild.

One more thing to mention: there has been some development since writing this: GeoSPARQL 1.1 defines a SpatialMeasure class in which it is recommended to use a UOM URI from the OGC Definition server. However, looking at the list of UOMs there, it is very incomplete. I'm not aware of plans to expand this.  http://www.opengis.net/def/uom

**[13.6] is about the idea of having a samePlaceAs property**. We proposed to have this as a qualitative assertion based on human perception that two things are the same place (as opposed to / in addition to topological assertions). At the time we said "A continuation of the SDW WG intends to formally define samePlaceAs." But we never did, and perhaps the need we felt to have this has dissipated? I'm curious to hear what the group thinks. If nobody thinks we need this anymore, we could drop this as a Gap altogether - or else do the work. 

**[13.7], finally, is about the lack of a way to discover what refers _to_ a spatial thing** (incoming links). The main possible approach, as described in this Gap section, boils down to using VoID with Linksets. I think that when we look, we would see this being used more in practice now. I know of the Kadaster using this. If others can confirm this we might promote this one to a best practice. 

[13.1]: https://www.w3.org/TR/sdw-bp/#c-geometrycrs
[13.2]: https://www.w3.org/TR/sdw-bp/#c-spatialdatavoc
[13.3]: https://www.w3.org/TR/sdw-bp/#describing-dataset-structure-and-service-behaviors
[13.4]: https://www.w3.org/TR/sdw-bp/#c-dynamicdata
[13.5]: https://www.w3.org/TR/sdw-bp/#c-unitofmeasure
[13.6]: https://www.w3.org/TR/sdw-bp/#c-sameplaceas
[13.7]: https://www.w3.org/TR/sdw-bp/#c-inboundlinks

-- 
GitHub Notification of comment by lvdbrink
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1259#issuecomment-832719043 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 5 May 2021 14:09:39 UTC