BP 2017 reordering proposal

From Spatial Data on the Web Working Group
Jump to: navigation, search

Introduction

The working group decided to reorder the best practices in the SDW BP and this page describes the options that were considered. Option 5 was selected (see minutes) and has been implemented in the Editor's draft in april 2017.

Constraints and analysis

Up front, it is important to keep in mind that the following best practices are to be deleted, so these BP numbers do not feature in any of the proposals below:

  1. BP2
  2. BP12
  3. BP13
  4. BP15
  5. BP16

I did some analysis on which BPs are referring to which. Each reference means there is a relationship between two BPs.

In some cases it can be said (and is said in some cases) the relationship is of type prerequisite. This gives us an indication of a preferable order (we might say that BPs that are a prerequisite for another should come before the other in document order).

In other cases the relationship is of type more detail. This suggests that the more detailed BP might come after the other one.

In yet other cases it's nothing more than a see also, which doesn't really tell us anything about a preferred order.

  1. BP1: Include spatial metadata in dataset metadata
    1. BP5 (see also)
  2. BP3: Choose the coordinate reference system to suit your user's applications
    1. BP17 (see also)
  3. BP4: Make your spatial data indexable by search engines
    1. BP1 (not mentioned in the text, but it is sort of a prerequisite to have metadata before you can publish dataset metadata as HTML)
    2. BP7 is a prerequisite
    3. BP11 (provides more detail)
    4. Section 12.6 Spatial Data Access
  4. BP5: Describe the positional accuracy of spatial data
    1. none
  5. BP6: Describe properties that change over time
    1. none
  6. BP7: Use globally unique persistent HTTP URIs for spatial things
    1. Section 12.7 Linking Spatial Data
    2. BP4 (sort of follows from BP7, because "publishing spatial data on the Web means that the URIs for each spatial thing should resolve to Web pages or data resources that provide useful information")
    3. BP11 (provides more detail)
  7. BP8: Provide geometries on the Web in a usable way# BP10: Encoding spatial data
    1. BP3 strictly correlated
    2. BP17 strictly correlated
    3. BP4
    4. BP10 more detail
    5. BP14 more detail
  8. BP9: Describe relative positioning
    1. none
  9. BP10: Encoding spatial data
    1. BP7 (not mentioned in the text as a prerequisite for BP10 but seems clear from the description that it is)
    2. BP4 more detail
    3. BP8 (not mentioned in the text as a prerequisite for BP10 but could be seen as such or at least as info you need before)
  10. BP11: Expose spatial data through 'convenience APIs'
    1. BP 4 more detail
  11. BP14: Publish links between spatial things and related resources
    1. BP7 is a prerequisite
    2. BP11 more detail
    3. BP4 (not really a prerequisite but close)
  12. BP17: State how coordinate values are encoded
    1. BP1 more detail

Proposal 1: Reordering based on workflow

This is a proposal for reordering the best practices based on workflow. Input: section 11 from the best practice and the Delft f2f discussion (Jeremy's proposal). The basic idea is that first of all, to make spatial data available on the Web you assign URIs. This includes dealing with versioned resources. Then the next question is how to describe the data (including accuracy, CRS, geometry, etc.). And perhaps you are using relative positioning. Once all this is done, another step that is useful is linking the data. Then, make sure the data can be found and accessed.

(headings are just suggestions at this point. At least they show it is possible to group the BPs into sections when using this ordering.)

Publishing on the Web

  • BP7: Use globally unique persistent HTTP URIs for spatial things
  • BP6: Describe properties that change over time

Expressing spatial data, geometries, and coordinates

  • BP10: Encoding spatial data
  • BP3: Choose the coordinate reference system to suit your user's applications
  • BP8: Provide geometries on the Web in a usable way
  • BP17: State how coordinate values are encoded
  • BP5: Describe the positional accuracy of spatial data
  • BP9: Describe relative positioning

Linking

  • BP14: Publish links between spatial things and related resources

Discovery and access

  • BP4: Make your spatial data indexable by search engines
  • BP11: Expose spatial data through 'convenience APIs'
  • BP1: Include spatial metadata in dataset metadata

Proposal 2: based on reading order

For a reader it would be nice if, when reading in document order, the BPs would not reference other BPs that he/she has not yet read about.

However, from the way BPs reference each other, it is not possible to order them in such a way that no BP refers to one that comes after it. For example, BP 7 refers to BP4 and BP4 also refers to BP7. But we could put the BPs that are most often referred to, earlier in the document.

We should also take into account which BP is really a prerequesite for another.

The proposal is then:

  1. BP7 (referenced by 4, 10 and 14, twice as a prerequisite)
  2. BP4 (referenced by 7, 8, 10, 11 and 14)
  3. BP11 (referenced by 7, 4 and 14)
  4. BP3, BP17, BP10 and BP14 (because referenced by BP8)
  5. BP8
  6. the rest

Proposal 3: Reordering the sections not the BPs

It might be possible to retain the sections that hold the BPs, instead of reordering the BPs themselves and having to introduce new sections that group and introduce them.

The sections currently are:

  • 12.1 Spatial Metadata
  • 12.2 Spatial Data Quality
  • 12.3 Spatial Data Versioning
  • 12.4 Spatial Data Identifiers
  • 12.5 Spatial Data Vocabularies
  • 12.5.1 Describing location
  • 12.5.2 Publishing data with clear semantics
  • 12.5.3 Temporal aspects of spatial data
  • 12.6 Spatial Data Access
  • 12.7 Linking Spatial Data

A logical reordering would be, based on reading order:

  1. Spatial Data Identifiers
  2. Spatial Metadata
  3. Spatial Data Access
  4. Spatial Data Vocabularies
  5. Linking Spatial Data
  6. Spatial Data Quality
  7. Spatial Data Versioning

However, this means that BP1 would still be the second BP in document order. And where would BP17 go?

Proposal 4: reordering based on priority

Reordering based on priority is maybe tricky and difficult to get consensus on. However, it might be possible if we consider the question: which best practices are really the key ones for succesfully publishing spatial data on the Web'?

For publishing data on the Web, it is really important to read the BPs on URIs for spatial things and on making data crawlable.

For publishing spatial data on the web the must reads are the BPs on geometry encoding, spatial data encoding, and coordinate reference systems.

From the data user perspective, data access is really important, so the BP about convenience APIs should be next.

After these important topics have been addressed the document can move on to the topics of metadata (important for discovery on the dataset level and for judging fitness for purpose), and linked data (for more advanced data users).

Last of all the more detailed subjects of publishing changing data (BP about spatial things that change over time) and relative positioning.

So the proposal is (headings are just suggestions at this point):

Spatial data Webiness

  • BP7
  • BP4

Key spatial aspects of Web data publishing

  • BP8
  • BP10
  • BP3
  • BP17

Spatial data Access

  • BP11

Spatial metadata

  • BP1
  • BP5

Linking Spatial Data

  • BP14

Other spatial aspects

  • PB6
  • BP9


Proposal 5: Thematic & prioritised ordering

(an evolution of Proposal 4 from Jeremy)

Note that at Delft f2f we agreed to refactor BP8 and BP14 into two parts:

  • BP8a :: general geometry publication
  • BP8b :: multiple geometries
  • BP14a :: general linking (not spatial at all - but DWBP didn't mention this stuff)
  • BP14b :: link relation types for spatial data

(working names for the refactored elements of the best practices - I know we can do better)

I also think that BP10 sets the tone for the "key spatial aspects" as it introduces the four categories of spatial data publication (simple, web app, data integration, spatial analysis) - this feels like a good starting point when we talk about the spatial content.

Looking again, the "other" section in Proposal 4, this feels like it's always going to be a poor relation. Although my next suggestion busts the "priority" ordering, I wonder if these two should be included in the section where we talk specifically about the content that makes data into spatial data (e.g. section #2 "Spatial data")? BP9 kind of goes with the other CRS best practices (although I think we should be clear in the section intro that relative positioning is not relevant to every application; and BP6 is about spatial data so could be appended to that group of best practices.

So my suggestion for a re-ordering/re-structuring is...

Web principles

  • BP7
  • BP4
  • BP14a

Spatial data

  • BP10
  • BP8a
  • BP8b
  • BP3
  • BP17
  • BP9
  • BP14b
  • BP6

Access

  • BP11

Metadata

  • BP1
  • BP5

(the best practices from Proposal 4's _linking_ and _other_ sections are incorporated elsewhere so are no longer needed)

Given that we only have one Access best practice, it may seem appropriate to conflate Access and Metadata sections; I'd prefer not to:

  1. what we're proposing is quite different to how OGC has traditionally done web services - I wouldn't want that to get lost
  2. we make a lot of reference to DWBP from here, so although _we_ have only one BP, there's a brace of best practices (new collective noun!) that are mentioned


Proposal 6: Geometry, Identifiers, linking geo & non-geo data, publication, consumption

(alignment with work done elsewhere on guiding principles in stats community (Laurent))

One of my ABS colleagues working on Spatial Data is the leader of the Global Statistical Geospatial Framework initiative which in a nutshell is one of the places where statistical agencies are working together towards  the convergence of geospatial and statistical data infrastructures (and also monitoring the developments around open data and linked data infrastructures). For some context, see his EFGS 2016 talk last year: Progress on the Global Statistical Geospatial Framework : http://www.efgs.info/wp-content/uploads/conferences/efgs/2016/Session-1-Martin-Brady.pdf

What I have done below is that I have taken the “guiding principles” presented by Martin and mapped them to the BPs (SDW BP and DWBP). With the discussion on BP_reordering, and no proposals above similar to it, I thought it was a good time to share this content (I have updated it the best I could to be up-to-date with the planned changes). There is also some extra content below (relationships to DWBP and DWBP benefits) which I hope will be useful.

What I learned doing this exercise is that the BP document contains less advice on how to mix spatial data and non-spatial data than I expected (hoped for). Two other points are worth mentioning:

  • My colleagues are interested in the repeatability and quality of the geocoding process (a good practice here is to supply a geocoding API to minimise the risks of “wrong geocoding”: this is a particular type of convenience API which may be worth mentioning).
  • I am also very interested in is the management of IDs for time-varying geospatial features. You can see in the table it is hard for me to decide if the current label for BP6 is applicable only to datasets or both for datasets and entities (maybe some of our readers will also be confused).
Sub-parts of SDW Best Practices (re-arranged by Laurent) Guiding principles of the proposed UNGGIM GSGF Best practices
·         Geometry

 

Reuse.png Comprehension.png Processability.png Interoperability.png 

 

·         Principle 1: Use of fundamental geospatial infrastructure and geocoding; BP3: Choose the coordinate reference system to suit your user's applications

 

BP17: State how coordinate values are encoded

 

BP9: Describe relative positioning

 

 

 

 

·         Identifiers

 

Reuse.png Linkability.png Interoperability.png Discoverability.png 

·         Principle 1: Use of fundamental geospatial infrastructure and geocoding;

·         Principle 2: Geocoded unit record data in a data management environment;

 


BP 7: Use globally unique persistent HTTP URIs for spatial things

DWBP 10: Use persistent URIs as identifiers within datasets

 

BP6 describing properties that change over time

only for datasets?

DWBP 8.6 Data Versioning

 

DWBP 7: Provide a version indicator

DWBP 8: Provide version history

DWBP 9: Use persistent URIs as identifiers of datasets

DWBP 21: Provide data up to date

 

·         Geographical features (and themes)

 

Reuse.png Comprehension.png Processability.png Interoperability.png 

·         Principle 3: Common geographies for dissemination of statistics;

·         Principle 4: Interoperable data and metadata standards; and

BP14: Publish links between spatial things and related resources
·         Production of geospatial data (for the web)

 

Processability.png Comprehension.png Discoverability.png Interoperability.png Access.png 

·         Principle 4: Interoperable data and metadata standards; and BP 1: Include spatial metadata in dataset metadata

DWBP 1: Provide metadata

DWBP[1]2: Provide descriptive metadata.

DWBP 3: Provide structural metadata

 

BP10: Encoding spatial data

BP5: Describe the positional accuracy of spatial data

DWBP 6: Provide data quality information

 

BP3: Choose the coordinate reference system to suit your user's applications

DWBP 6: Provide data quality information

 

 

·         Consumption of geospatial data (on the web)

 

Comprehension.png Access.png Trust.png Discoverability.png Interoperability.png 

 

·         Principle 5: Accessible and usable geospatially enabled statistics  

BP8: Provide Geometries in a web friendly way

 

BP11: Expose spatial data through 'convenience APIs'

 

BP4: Make you data indexable by search engines DWBP 1: Provide metadata

DWBP 2: Provide descriptive metadata

DWBP 3: Provide structural metadata

DWBP 9: Use persistent URIs as identifiers of datasets

DWBP 10: Use persistent URIs as identifiers within datasets

DWBP 15: Reuse vocabularies, preferably standardized ones

 

DWBP5: Provide data provenance information

 

 

 

 


Best practice group Best practice Benefit
  BP 1: Include spatial metadata in dataset metadata

DWBP 1: Provide metadata

DWBP[2]2: Provide descriptive metadata.

DWBP 3: Provide structural metadata

Reuse.png Discoverability.png 
  BP3: Choose the coordinate reference system to suit your user's applications Reuse.png Comprehension.png Processability.png Interoperability.png 
  BP4: Make you data indexable by search engines

DWBP 1: Provide metadata

DWBP 2: Provide descriptive metadata

DWBP 3: Provide structural metadata

DWBP 9: Use persistent URIs as identifiers of datasets

DWBP 10: Use persistent URIs as identifiers within datasets

DWBP 15: Reuse vocabularies, preferably standardized ones

Access.png Trust.png Discoverability.png Interoperability.png 
  BP5: Describe the positional accuracy of spatial data

DWBP 6: Provide data quality information

Reuse.png Trust.png Interoperability.png 
  BP6 describing properties that change over time

only for datasets?

DWBP 8.6 Data Versioning

 

 DWBP 7: Provide a version indicator

DWBP 8: Provide version history

DWBP 9: Use persistent URIs as identifiers of datasets

DWBP 21: Provide data up to date

Comprehension.png Trust.png Access.png 
  BP 7: Use globally unique persistent HTTP URIs for spatial things

DWBP 10: Use persistent URIs as identifiers within datasets

Reuse.png Linkability.png Interoperability.png 
  BP8: Provide Geometries in a web friendly way Reuse.png Access.png Discoverability.png Interoperability.png 
  BP9: Describe relative positioning Reuse.png Comprehension.png Processability.png Interoperability.png 
  BP10: Encoding spatial data Processability.png Discoverability.png Interoperability.png 
  BP11: Expose spatial data through 'convenience APIs' Access.png Processability.png Discoverability.png Interoperability.png 
  BP14: Publish links between spatial things and related resources Reuse.png Linkability.png Processability.png Interoperability.png 
  BP17: State how coordinate values are encoded Reuse.png Comprehension.png Processability.png Interoperability.png 

 

 

_