We need to complete the list of things that are out of scope, and also to describe better what is IN scope.

Best Practice 21: Link to spatial Things includes an example where we link to a resource as it was at a particular time. What is the best way to do this? Point to particular version of the target resource or provide date-time context with the assertion?

Is there any evidence that can be used to support either approach?

Also see Best Practice 4: Provide stable identifiers for Things (resources) that change over time and Best Practice 11: How to describe properties that change over time.

@fransie said in point (3) of his email to the WG

In paragraph 1.1 discoverability and accessibility are listed as the key problems. I think interoperability (between different publications of spatial data and between spatial data and other types of data) could be listed as a third main problem; many requirements have to do with interoperability.

Kerry Taylor noted in her email that she "can't distinguish this group from [geospatial experts] nor [web developers]".

Do we need a content publishers category in section 2. Audience?

Relating to Best Practice 25: Make your entity-level data indexable by search engines, are there any examples of a search engine indexing structured spatial data such as KML or GeoJSON? Both of these formats seem to have good support from Google; but do these formats get crawled and indexed?

Also see #179.

The Example Best Practices section is a placeholder and can be removed as soon as we have some real content to replace it.

Search for /.well-known/void on a specified set of domains? Is there any practice in the wild that can be referenced?

One of our principles states: "Best versus emerging practices will be clearly recognizable in this document."

We need to come up with a way to make this clear in the document.

For example: sensor data streams

(see Best Practice 11: How to describe properties that change over time)

The principles section currently includes only a link to the principles list in the wiki.

Not all of these are applicable; need to review.

Seems to make sense to add relevant principles to Context or Scope sections of the BP document.

... to determine if there are any best practices without associated requirements.

In the audience section we mention two different groups: Geospatial experts without web knowledge and Web developers without geospatial knowledge.

With regards to the first group, Geospatial experts without web knowledge, we need to determine if we are indeed targetting them.

Secondary issue: developer audiences are sometimes described as the Large set of unknown developers and the Small set of known developers. Is this a useful distinction for us to make?

More content is needed for Best Practice 5: Provide identifiers for parts of larger information resources| ids-for-chuncks. Especially the approach and how to test sections.

Relating to Best Practice 25: Make your entity-level data indexable by search engines, are there any examples of a search engine indexing data that is provided as a record in a dataset or data-stream? Especially where that data is not exposed as an HTML page?

How do search engine Web crawlers work with that kind of data?

Section 6.5 Exposing datasets through APIs includes Best Practice 30: Include search capability in your data access API. This might be better suited in section 6.4 Enabling discovery.

Add reference to DWBP BP 11 (if this is still the correct number - I don't remember what the BP was about), once Phil Archer gets this addition approved by the DW WG.

This reference goes into the section Assigning identifiers to real world things and information resources

It is often in social discourse useful to identify spatial things even though they're fuzzy. Do we need a subclass of SpatialThing or a property that expresses the fuzziness of a spatial thin? Is there something like this in current or emerging practice?

Best Practice 19: Make your entity-level links visible on the web contains only outlines of examples. Further details need to be added.

How do we know what is at the end of a link - and what can I do with it / can it do for me (e.g. the 'affordances' of the target resource).

Erik Wilde says: "'webby data' is a necessary but not sufficient condition to have hypermedia; hypermedia is not (only) about linking data (i.e., using "web data"), it's also about providing navigational affordances to get things done with that data. this means that the links are about services (or whatever you might call this)."

We might publish in the SDW BP or a complimentary note a set of statements mapping the set of available vocabularies about spatial things. There are mappings available: e.g. GeoNames has a mapping with schema.org.

In the section Dealing with large datasets, should we discuss scaleability?

If so, content is needed for this.

The Basic Geo vocabulary has a class SpatialThing which has a very broad definition. This is not a problem for a lot of use cases. However, for some use cases we might need something more specific.

A starter for 10 on the main differences ...
Best Practice 1: Use globally unique identifiers for entity-level resources
Best Practice 19: Make your entity-level links visible on the web
Best Practice 28: Expose entity-level data through ‘convenience APIs’

The question is whether we need this as a Best Practice or not; There don't seem to be many existing solutions/best practices for this.

If the answer is yes we need it, then please help to add more content to this BP.

BP10: We need some explanations for the appraohes to describe positional (in)accuracy

The introduction is being reviewed by the SDW WG. Review comments are here.

@edparsons said in his email to the WG:

I think we have to be very careful with this section, we are rather loose with language. This is quite a good starting point as to why people use different CRS.

'data related to a specific location' seems to exclude coverage data. This is not the intention, the scope includes coverage data. New wording is necessary to make this clear in the introduction.

Frans, can you suggest new wording?

By "entity-level resources" the BP editors are talking about the descriptions (information objects) of the SpatialThings (the entities) in a dataset ... the discrete components that comprise the dataset.

In her email, Kerry Taylor wonders if the term "entities" is sufficient. I'm not sure that this covers the intended scope. Should we be saying "SpatialThing"?

With the exception of Best Practice 30: Include search capability in your data access API, the information in section 6.5 Exposing datasets through APIs seems to be largely applicable to all kinds of data published on the web - not just spatial data. Is there merit in moving the content to DWBP section 9.11 Data Access?

Somewhere we need to talk about making OGC WxS services more "web friendly" and compatible with linked data approaches ... this section seems like the most appropriate place. Alternatively, we could provide this kind of information in an Appendix or even a separate Note?

Does the Beacon link dump format allow the use of wild cards / regex in URLs (e.g. URI Template as defined in RFC6570)?

Including:

• discussion on ‘punning’ to allow conflation of concerns? ref @timbl’s statement about vCard; ref URIs in data primer for direct and shorthand properties?
• discussion on identification of coverages as a property of a Thing
• how to mint the identifier yourself based on the features in your dataset and how the identifier is for the real world thing the feature describes.

Regarding Best Practice 11: How to describe properties that change over time Kerry says in her email:

This looks a bit heavy-handed for many use cases --- can it also allow that it is ok not to provide time and/or location stamps and allow tracking of changes? Under what circumstances might it be best practice to leave these out? Why do we not ask this for all the rest of the data on the web?

Especially the Possible Approach to Implementation section needs more content. But perhaps also the Why section.

Notes not yet included in the text:

• incorporates assignment of URIs based on scoped identifiers (e.g. Feature IDs from a dataset or local identifiers within tabular data); assignment of URIs to ‘blank nodes’ (plus note on subsequent reconciliation; non-unique naming is inevitable) … SIRF, schema.org etc.
• something about toponyms?
• should this move to “Exposing data through APIs” section? (Not in my opinion - lvdbrink)

The BP document currently contains a conformance section. Given that this document is a Note, do we need this section?

Is the Data on the Web template to describe Best Practices suitable for our BP as well? Or do we need changes/additions to this template?

Relating to Best Practice 25: Make your entity-level data indexable by search engines, more discussion is required on how to structure meaningful (spatial) queries with search engines (e.g. based on identifier, location, time etc.).

In her email Kerry notes:

I like those worded in an imperative style like "xx should be yyy" , over those worded in the "how to" style. I think the latter kind should be rewritten to the former kind.
e.g. "How to describe relative positions" could be " Relative positions should be expressed in a machine-interpretable or human readable manner"

Our Best Practice 2: Reuse existing (authoritative) identifiers when available looks like it could be a duplicatie of Best Practice 22: Link to resources with well-known or authoritative identifiers.

The first is in the Assigning identifiers section, the second in Linking spatial data. I added content to the first one today. Please check whether they are duplicates and if BP 2 content should be moved to BP 22, and removed.

Relating to Best Practice 4: Provide stable identifiers for Things (resources) that change over time, Kerry notes in her email:

I wonder whether some reference to the paradox of the Ship of Theseus would be useful here
just to highlight the fact that there is no really rigorous notion of persistent identity.

Which vocabularies out there have social spatial relationships? FOAF, GeoNames, ...

By social spatial relationships we mean relationships that are not geometric or topological, but for example hierarchy relationships like one region being part of another.

NB it is not clear to me what is meant by social spatial relationships. Is partOf a good example? Are there others?

The Requirements listed in the Use Case and Requirement document are listed by number only ... which is a fragile referencing system should the doc section numbers change. Typically within W3C documents the Requirements are given short-names to make them easier to refer to. For example, refer to the DWBP UCR document.

So for example, our first requirement 5.1 Bounding box and centroid might be named R-BoundingBoxCentroid. I think that most of the work has already been done here, as the section element for each requirement already has a short-name in the id attribute; e.g. BoundingBoxCentroid.

Regarding Best Practice 5: Provide identifiers for parts of larger information resources Kerry notes in her email:

I don't like "subset" being used for this purpose -- despite its popularity in spatial arenas, for its lack of clarity being a misused mathematical term. Database language of "select" and "project" are preferable, but still too narrow. What do you think of "view"?

A resource may be linked to many other resources. More so, an authoritative resource, such a government published administrative areas, may be referred to by thousands of other resources.

How do we expect user agents to handle this multitude of links - given that the standard document-web model provides only a single target for a hyperlinked <a> element?

need to provide summary of the approach to implementation and enable readers to drill-down to more detailed documentation within each of the best practices- else this document will become (very) unwieldy

... in particular, this thought is inspired by Best Practice 19 Make your entity-level links visible on the web which already (prior to FPWD) has a lot of content.

The Data on the Web Best Practice is addressing discovery at the dataset level including spatial and temporal coverage. Either the DWBP or the SDWBP should refer to GeoDCAT-AP. It must be determined where this reference should go. If the DWBP will not reference it, the SDWBP should.

Best Practice 11 needs information about how to work with data that is such high volume (e.g. sensor data streams) that the data is discarded after a period of time.

Linksets does not seem to be an evidence-based best practice. It might be an emerging practice (e.g. the CSIRO example). This might go in a shared note with the DWBP. An example of expressing a collection of links from the library community is here. An example vocabulary for expressing link sets is in VoID.

When this note is published, add a reference to the SDW BP doc.

Why different coordinate ref systems exist needs to be explained in a brief overview on the subject for our non-geo-expert readers.

There is some Dutch text available at Geonovum we can use for this, but it still needs to be translated.

General introduction needs content.

Content sources:

• Charter
• Geonovum tender doc