Comments (4)
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
from pygeoapi.
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
- name: Api-title
- description: Api description
- author: Api contact
- dataset
- name: collection title
- description: collection description
- distribution: dataDownload
- contentUrl: features/collections/things/items?f=gml
- encodingFormat: application/gml+xml
- ...
- dataset
- name: collection title
- description: collection description
- distribution: dataDownload
from pygeoapi.
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.
from pygeoapi.
Implemented a lot of this in #246. In particular:
- Uses schema.org for the structured (meta)data about the pygeoapi instance itself, and the datasets it exposes. Uses
schema:Dataset
andschema:DataCatalog
to get into the Google dataset search by default. - For features and feature collections, does the minimal thing using the GeoJSON vocabulary as a mandatory default vocabulary. Allows for optional specification of additional
@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. - JSON-LD representations are embedded into each page (via a second request once the HTML is loaded; injected with a small JavaScript function).
- Microdata (
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.
from pygeoapi.
Related Issues (20)
- OAPIF examples have wrong encoding format
- ModuleNotFoundError: No module named 'jsonpatch' HOT 8
- Incorrect tileMatrixSetURI for well-known Tilesets
- mutable default arguments used in some providers
- Scan code base for vulnerabilities, secrets or misconfiguration
- Scan the Docker image for vulnerabilities before pushing to the registry HOT 1
- EDR providers lack support for /locations and locations/<location_id> queries
- Enable CQL filtering to accept filter geometries in any CRS HOT 1
- most recent version of starlette breaks pygeoapi CI
- allow running pygeoapi starlette with uvloop
- Improve documentation about Tile Publishing HOT 1
- Address requirement 5 of OGC API - Tiles Core Requirements HOT 1
- Address requirement 6A of OGC API - Tiles Core Requirements for the MVT-elastic provider
- pygeoapi serve runs pygeoapi web application twice HOT 3
- Serving tiles from a url on mvt-tippecanoe is not working HOT 1
- Error starting pygeoapi with django server
- Provide a default configuration if none given
- replace geoalchemy with geoalchemy2 as a dependency
- wfs provider tests fail occasionally HOT 2
- Make sqlalchemy a first level dependency for providers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pygeoapi.