Closed tomkralidis closed 4 years ago
schema.org is relevant in the html encoding of collections/features. However it can also be added to a json representation, as a json-ld context. But consider that json-ld is currently incompatible with geojson. To support json-ld a response encoding application/ld+json should be added.
Various vocabulaires exist to annotate geometry, a suggestion was made at the final geo4web conference why not add all of them. A selection can be made from geojson-ld, geosparql and https://schema.org/geo. Last years the schema.org/geo vocabulaire was limited, but it will probably improve.
There are generally 2 options to add schema.org annotations, embed a json-ld representation of the content or add microdata to each of the html tags. The first approach seems most valid, as a json representation of the object is already available in the software.
For each collection a configuration option should be added (like available in ldproxy) to define definitions for the objects in the collection (what type of schema.org/Thing (or any other vocab) does it contain). An alternative starting point could be the vocabulaires defined for INSPIRE. Then for each Feature property a mapping should be made to a schema.org property of the Thing. This configuration can then be used to generate the ld-context.
A good place to get started with structured text in html pages is https://search.google.com/structured-data/testing-tool
For the api and collections page, consider to define the parent (api) as a schema.org/DataCatalog, and each of the collections as a schema.org/Dataset, the api will then auto-popup in https://toolbox.google.com/datasetsearch
DataCatalog
I'm working on some of these ideas here https://github.com/spatialdaotearoa/pygeoapi/tree/ld-json as part of the SELFIE. At present I'm just creating JSON-LD representations (dynamically inserted into the HTML head
, if ...?f=jsonld
returns a 200 status) that are a (almost) 1:1 match for the microdata introduced in #91. If there was an acceptable JSON-LD alternative to the microdata, would pygeoapi support both or only one?
@pvgenuchten I'm intrigued by
For each collection a configuration option should be added (like available in ldproxy) to define definitions for the objects in the collection (what type of schema.org/Thing (or any other vocab) does it contain). An alternative starting point could be the vocabulaires defined for INSPIRE. Then for each Feature property a mapping should be made to a schema.org property of the Thing. This configuration can then be used to generate the ld-context.
and was wondering if you'd expand on this from an implementation perspective?
SELFIE has made some recommendations for a minimum set of vocabularies, and may have different opinions about DataCatalog
and so on, but it is striving to favour schema.org as much as possible. I think attention paid to good structured data representations by default will pay off with much better SEO and interoperability for any pygeoapi instance.
Implemented a lot of this in #246. In particular:
schema:Dataset
and schema:DataCatalog
to get into the Google dataset search by default.@context
via the YAML configuration of each collection. In #246 there is a more complicated Postgres example, including the possibility of linking across collections at the feature level.itemprop
s) retained in HTML templates.There's more that could be done, e.g. I haven't considered describing the type of each Thing:
@pvgenuchten For each collection a configuration option should be added (like available in ldproxy) to define definitions for the objects in the collection (what type of schema.org/Thing (or any other vocab) does it contain). An alternative starting point could be the vocabulaires defined for INSPIRE. Then for each Feature property a mapping should be made to a schema.org property of the Thing. This configuration can then be used to generate the ld-context.
My motivation was really the minimum viable inclusion of JSON-LD, and I'm happy to contribute more.
http://schema.org/