Spatial Data on the Web - Best Practice 2 - Value and approach for indexing individual Spatial Things

[MichaelGordon]

In both the GNAF Best Practice implementation report and NRW Best Practice implementation report, an issue has been encountered in relation to Best Practice 2: Make your spatial data indexable by search engines namely that there are millions of Spatial Things in each dataset and whilst the implementations create machine readable and indexable data for each Spatial Thing, the use of pagination to make the Spatial Things navigable for humans seems to impact the indexability.

In discussions in Lyon there was also some questions about the demonstrating the value of having each individual Spatial Thing indexable - however I believe there was reasonable consensus that allowing users to find a specific Spatial Thing and for machines to be able to create links between datasets containing information about specific Spatial Things was seen as having clear value - although the description of the value of the linking between spatial things or data about the same spatial thing could be improved in Best Practice 2.

I believe @cportele is going to look into the sitemaps approached discussed in Best Practice 2. We may also benefit from discussion on this issue from Ed Parsons.

[cportele]

INSPIRE has held a Workshop on making spatial data discoverable through mainstream search engines.

The linked page contains the program and for each contribution the abstract and the slides. For the discussion-slots, the slides contain also a summary of the discussion. There are also slides capturing the final discussion (conclusion and next steps).

Here is a summary from my personal notes (I have excluded aspects that are related to the usual metadata/catalog issues):

The workshop gave a helpful overview and had good discussions. There weren't really surprising results, but there were new insights on details and there are several activities related to the topic - it would be useful to monitor their progress/results, could also be input to future updates of BP2.

Most of the following is already in BPs 1 and 2, but there are also some new aspects.

Stable identifiers:

• Identifiers should be HTTPS URIs
• Minted URIs that redirect to your API, the minted URI is the canonical URI

Good web pages - which content?

• The provision of websites for features should primarily not be for search engines, but aimed at human users; they should provide information, not just display data, and generally be richer than the typical feature data in most records today
• Web pages for features can be automatically created with tools such as the implementations of OGC API features that match the JSON/XML content to the feature, but such pages are often of limited use to the intended audience without further customization
• Publishing features with persistent URIs and easily understandable information directly accessible to users can lead to more linking between data, more centralization and less copying
• There are different target groups; for example, developers (who are used to working with datasets and APIs, but can have no or only limited domain or GIS knowledge) or citizens (are not interested in the dataset, only in individual objects and have no domain or GIS knowledge/tools)
• The data content (HTML, but also in the JSON) should be formulated according to the requirements of the target group(s); test: How does the availability of the web pages improve the processes of the user?
• Web pages should describe real-world objects in terms that users would understand/use; these are often different from the language used by the domain experts
• Include/link to related information and actions on that resource that are relevant for the target users; for example, other info about the location, nearby things of interest, user feedback, workflows, etc.
• schema.org annotations, at least for pages you want to have indexed
• The information should be up to date and changes should be documented
• The context should be visible, especially for users who are used to working with data sets: For example, the feature page should be linked to the landing page of the dataset
• Tools: use structured markup tools to test that content is visible

Indexing by search engines:

• Focus on useful web pages first
• Decide what needs to be indexed, perhaps even exclude indexing unless features are referenced from a 3rd party
• Think about the user journey from the page
• Follow SEO practices and their tools; analyze queries that lead users to the page and monitor what happens
• Use of a separate host/domain, if applicable, to avoid impact/dilution of the indexing of many feature web pages on the ranking of other web pages in the domain

[marqh]

Hello @cportele

I am interested in:

* Identifiers should be HTTPS URIs

and encouraging a bit more information/discussion about it, if I may. Is this ticket an appropriate place for this?

There is widespread use of HTTP identifiers. Many existing vocabularies are published as HTTP URIs

A cursory search reveals some fairly recent debate on the issue, such as

• https://www.w3.org/blog/2016/05/https-and-the-semantic-weblinked-data/
• https://stackoverflow.com/questions/44883339/preferring-https-iris-on-the-semantic-web
• https://lists.w3.org/Archives/Public/semantic-web/2017Jul/0042.html

I wonder whether this issue has a degree of nuance which is not well covered by:

Identifiers should be HTTPS URIs

e.g.:

• how strong is 'should'?
• is this different for new vocabularies not yet published and vocabularies in use?
• is it advisable / strongly advisable to ensure that http://{thing} and https://{thing} resolve to the same thing? (This is critical for me, more important than 'use https now')
• what happens if the https URI returns a security violation (It happens: I guess many of us have experienced this, as a resource requestor and as a service maintainer)

If the target for this statement is a Best Practice guide, I wonder whether some nuanced commentary would be really valuable?

thank you marqh

[cportele]

@marqh

Yes, there are nuances not expressed in the statement, this was just from my notes. Let me add the following:

• This was only in relation to URIs of published features/datasets, not URIs in general and not about vocabularies.
• This was about new identifiers. I wouldn't expect any impact on existing identifiers.
• It is meant as a recommendation, not a requirement.
• In my view, http://{feature} and https://{feature} should identify the same feature and resolve to the same document. At least where both protocols (http, https) are supported by the server.
• What do you have in mind with respect to "security violations"? The only thing that comes to mind is the case where the server uses an invalid certificate and client libraries throw errors because of the security policies. In that case the server configuration is broken.