HTML not optimal for findability/discovery

[pebau]

clause_6_overview.adoc, under "Encodings", claims that search engines can exploit HTML contents. This is true only at the lowest level: HTML describes syntax, not semantics (remember why we introduced XML and RDF?), hence semantic search a the level required today is not possible.

• The corresponding text should be changed to reflect modern technology and the state of the art.
• semantic-rich format should be supported.

[Schpidi]

Teleconference 20190426: This might be an issue for common.

[nmtoken]

HTML 5 does offer up some semantic elements:

<article>
<aside>
<details>
<figcaption>
<figure>
<footer>
<header>
<main>
<mark>
<nav>
<section>
<summary>
<time>

Though I think these are only sufficient to help clients understand the structure of the HTML document better, rather than impart any real meaning

There is also the W3C HTML Microdata extension (working draft) ~ https://www.w3.org/TR/microdata/ that might be worth looking at. No idea of how well supported this is at the moment.

[cmheazel]

Clause 6 does not claim that HTML is optimal. Just that it is commonly processed by web crawlers to enable discovery (search). Low hanging fruit and nothing more.

[pvgenuchten]

Did you consider use of RDFa, microdata or embedded json-ld to enrich html with semantics?
see for example https://developers.google.com/search/docs/data-types/dataset.

[cmheazel]

I don't believe we preclude it. But do we need it in the spec? Our guiding principle for the core is to keep it simple. A corollary is that anything not prohibited is allowed. So unless there is something in the semantic metadata that needs to be standardized, I think we have it covered.

[dblodgett-usgs]

This issue is missing the point. HTML, in this case stands is for traversable hypertext and natural language content that is useful to web-crawlers who serve the natural language search engine use-case and can't build useful search inferences based on structured data they have not been designed to use.

The prospect of using semantic HTML and schema.org meta-content is very appealing and should potentially be a recommendation in core, but is not the business of the coverages spec IMHO. Most of this kind of content could just be dropped and moved to OGC-API Core?

[cmheazel]

The current version (12/30/19) provides conformance classes for HTML and JSON. Additional formats can be added if there is sufficient interest. These would basically be a clone of the existing conformance classes but with format-specific validation requirements (and schema).

[pebau]

Couldn't agree more to what Dave says above, except that it may make sense to describe the mapping of a coverage to its HTML representation given that coverages are particular beasts. A separate (non-mandatory) conformance class seems like a good place for this.

[cmheazel]

I would like to keep this discussion in Coverage for now because coverages provide a good use case. Plus, the Sprint next week gives us a good venue to work this issue.

Range Sets are usually delivered using a binary format such as GeoTIFF. HTML is not out of the question for Domain Sets, Range Types, etc. So how do we design an API standard where an encoding format may not be valid on all paths? How do we indicate that multi-part encodings are allowed and what the permitted parts are? We need to solve this problem for Coverages, then roll the answer back into Common.

[pebau]

see WCS, it defines exactly this, including controls.
But again, a rangeset is not a coverage, but just an unstructured collection of values.

[pvgenuchten]

So how do we design an API standard where an encoding format may not be valid on all paths?

This is exactly what the open api specification provides, in the api document you have to indicate which response encodings are available for which paths.

[Schpidi]

Teleconference 20200708: Clarified that the encoding discussed here is about response encoding other than Coverages themselves like for example the landing page.