Updates to the Spatial Data on the Web Best Practice NOTE

[6a6d74]

Discussion at the teleconf (Thu 25 Jun 2020) concluded that we should recharter as a Working Group scoped to update the Best Practice NOTE (and potentially other stuff).

Clara Boyd (Ordnance Survey) supported by the IG as the new lead editor.

ACTION: Jeremy, Linda, and Clara (with support from Ted) to begin working on a new WG Charter.

My notes from the teleconf below. Official minutes here.

——
(Ed & RobS)
Discussion about ethics of location sharing - “here be dragons”
(Clemens)
General conclusion: structure and content mostly good
… only needs updates
… especially examples (some don’t work any more | HTTP 404)
… plus new examples
… additional topics:
… OGC API work - update the API chapter and “what’s wrong with SDIs”
… there’s a very heavy RDF bias in the Relationships section; mostly the OGC APIs use “web linking”
… increasing use of “tile” concepts (noting the work in OGC to standardise the conceptual model and the tiles API) - there is practice in this space, even if not yet standardised
… dynamic CRS etc. (relating to BP8)
(Bill)
… DCAT version 2 (and potential to feed into ongoing DCAT discussions)
… schema.org updates - there’s been lots of implementation in this space
… linking spatial and non-spatial data - this is much easier with OGC API
… JSON LD 1.1 makes it much easier to use with GeoJSON - this is a prime candidate for how examples can be updated
(RobA)
… FAIR Principles
… more than just DCAT; people are sharing data in ad-hoc ways (e.g. PDF docs); there’s lots of work to improve with ad-hoc data sharing [to improve (re-)usability of that data] using profiles and JSON-LD
… most people do JSON-LD poorly thanks to the tooling; the @context files are often huge
… best practice around modularity of @context files (separation of concerns), registering profiles (for re-use), and linked data descriptions of profiles

[akuckartz]

… there’s a very heavy RDF bias in the Relationships section; mostly the OGC APIs use “web linking”

The RDF "bias" hopefully was considered to be a good thing.

[rob-metalinkage]

note: my comment was that data models (as metadata) are being shared in ad-hoc ways. I wasnt attempting to cover the more general issue of data sharing ;-)

[rob-metalinkage]

also,my main point about JSON-LD modularity was that tooling to support a best practice (actually around JSON-LD modules being FAIR) are being developed and tested in some projects at the moment, and the SDWIG will be kept in the loop and welcome to contribute.

[lvdbrink]

We will use this issue to provide the overview of all the updates we want to do on the BP (at least for now, we can choose later to use the existing Github project for this, but it needs a cleanup).

• DCAT 2 update (already done by Andrea Perego)
• Adding a section (we thought it should go in the Gaps part) about ethics of location sharing: making clear there are privacy and other ethical dangers to location sharing, and referring to the responsible use doc. One of the editors of that document might help.
• Updating examples throughout the doc and adding new examples. Bill Roberts had some specific ideas for improvements and some ideas for examples related to schema.org (BP2), JSON-LD 1.1 etc.
• Feeding OGC API evolution into the BP. An update of the API BP and the "whats wrong with SDI's" section, possible also other sections.
• Clemens Portele mentioned RDF bias in the Relationships section. This needs discussion, but perhaps Clemens could add examples using Web linking. Bill Roberts also mentioned that linking spatial and non-spatial data is much easier with OGC API, so he might also want to help.
• Add something on Tile concept (noting the work in OGC to standardize the conceptual model and the tiles API), perhaps a BP - needs further discussion in the group. We only touched on this.
• Update BP 8 with respect to dynamic CRS.
• Add FAIR principles to the document.
• The implementation reports that were made earlier should be scanned for input for the BP.
• Review BP for any updates necessary to the Gaps in current practice section and any things from the Gaps section that have matured enough to feed into the main BP. I already did some work on this. See Analysis of Gaps in current practice #1259
  – Review document for accessibility i.e. how understandable it is for the different target audiences
• Add a best practice about geofences. See Communicate good practice for defining geofences in the Best Practices doc #1268
• Clarify section on Coverages Clarify 'Coverages' section in SDWBP #1265

[jvanulde]

With respect to the FAIR principles I have found that some organizations, mine included, tend to take a less principled approach in their implementation - possibly to limit the impact of the directive/policy. Might I suggest that we provide specific examples of how spatial data should be provided in order to be compliant with a principled application FAIR. The goal would be to remove any ambiguity about how FAIR should be applied to spatial data.

[andrea-perego]

@jvanulde said:

With respect to the FAIR principles I have found that some organizations, mine included, tend to take a less principled approach in their implementation - possibly to limit the impact of the directive/policy. Might I suggest that we provide specific examples of how spatial data should be provided in order to be compliant with a principled application FAIR. The goal would be to remove any ambiguity about how FAIR should be applied to spatial data.

About this, it might turn useful some work carried in the Research Data Alliance (RDA) in order to define precise criteria to assess compliance with the FAIR principles (which are by themselves quite high-level). The first output of this activity is documented in the following report:

FAIR Data Maturity Model Working Group. (2020). FAIR Data Maturity Model. Specification and Guidelines (1.0). https://doi.org/10.15497/rda00050

[lvdbrink]

About this:

RDF bias in the Relationships section. This needs discussion, but perhaps Clemens could add examples using Web linking. Bill Roberts also mentioned that linking spatial and non-spatial data is much easier with OGC API, so he might also want to help.

@BillSwirrl has recently done some work for a Dutch API testbed including investigation of the link header in OGC APIs vs relations as item properties. I think it would be useful and helpful to feed this into the BP Relationships section.