Warning:
This wiki has been archived and is now read-only.

BP 2017 reordering proposal

From Spatial Data on the Web Working Group

Jump to: navigation, search

1 Introduction
2 Constraints and analysis
3 Proposal 1: Reordering based on workflow
4 Proposal 2: based on reading order
5 Proposal 3: Reordering the sections not the BPs
6 Proposal 4: reordering based on priority
7 Proposal 5: Thematic & prioritised ordering
8 Proposal 6: Geometry, Identifiers, linking geo & non-geo data, publication, consumption

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:

BP2
BP12
BP13
BP15
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.

BP1: Include spatial metadata in dataset metadata
1. BP5 (see also)
BP3: Choose the coordinate reference system to suit your user's applications
1. BP17 (see also)
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
BP5: Describe the positional accuracy of spatial data
1. none
BP6: Describe properties that change over time
1. none
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)
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
BP9: Describe relative positioning
1. none
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)
BP11: Expose spatial data through 'convenience APIs'
1. BP 4 more detail
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)
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:

BP7 (referenced by 4, 10 and 14, twice as a prerequisite)
BP4 (referenced by 7, 8, 10, 11 and 14)
BP11 (referenced by 7, 4 and 14)
BP3, BP17, BP10 and BP14 (because referenced by BP8)
BP8
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:

Spatial Data Identifiers
Spatial Metadata
Spatial Data Access
Spatial Data Vocabularies
Linking Spatial Data
Spatial Data Quality
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

Key spatial aspects of Web data publishing

BP8
BP10
BP3
BP17

Spatial data Access

BP11

Spatial metadata

Linking Spatial Data

BP14

Other spatial aspects

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

(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:

what we're proposing is quite different to how OGC has traditionally done web services - I wouldn't want that to get lost
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

Error creating thumbnail: Unable to save thumbnail to destination

· 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

Error creating thumbnail: Unable to save thumbnail to destination

· 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)

Error creating thumbnail: Unable to save thumbnail to destination

· 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)

Error creating thumbnail: Unable to save thumbnail to destination

· 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)

Error creating thumbnail: Unable to save thumbnail to destination

· 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	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP3: Choose the coordinate reference system to suit your user's applications	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	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	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP5: Describe the positional accuracy of spatial data DWBP 6: Provide data quality information	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	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	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP 7: Use globally unique persistent HTTP URIs for spatial things DWBP 10: Use persistent URIs as identifiers within datasets	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP8: Provide Geometries in a web friendly way	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP9: Describe relative positioning	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP10: Encoding spatial data	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP11: Expose spatial data through 'convenience APIs'	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP14: Publish links between spatial things and related resources	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination
	BP17: State how coordinate values are encoded	Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination Error creating thumbnail: Unable to save thumbnail to destination

Retrieved from "https://www.w3.org/2015/spatial/wiki/index.php?title=BP_2017_reordering_proposal&oldid=3931"

BP 2017 reordering proposal

Contents

Introduction

Constraints and analysis

Proposal 1: Reordering based on workflow

Proposal 2: based on reading order

Proposal 3: Reordering the sections not the BPs

Proposal 4: reordering based on priority

Proposal 5: Thematic & prioritised ordering

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

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Navigation

extra links

Tools