Future content negotiation

[Guts]

Purpose

Actually, resolve requests are using the application/xml mime-type: it's a feature, not a bug :wink:. Let's improve it! Goal: get a generic behavior to handle basic use cases and allow the end-user to fine tune it.

Different mime-types

• JSON: application/json
• GEOJSON: application/geo+json
• JSON LD: application/ld+json
• XML GML: application/gml+xml
• XML RDF: application/rdf+xml

Behavior

Mermaid syntax:

graph TD
    A[Feature instance description] -->|Resolve external| B(Request URI/L)
    B --> C{Content negotiation}
    C --> D[Profile settings]
    D --> C
    C -->|GET| E[application/ld+json]
    C -->|GET| F[application/gml+xml]
    C -->|GET| G[application/rdf+xml]
    C -->|GET| H[application/geo+json]
    E --> I{Response checker}
    F --> I
    G --> I
    H --> I
    I --> |KO| C
    I --> |OK| J{Response processor}
    J --> K([templating/rendering])

As image:

[sgrellet]

More content to anticipate future evolution on content negociation with services.

• An extract from the approach discussed within OGC SELFIE (https://github.com/opengeospatial/SELFIE/blob/master/docs/examples/fr/aquifer121AS01_BRGM_JSONLD.json)

The exemple below is an attempt to show the various representations of the same feature (French aquifer of code 121AS01) available from the same URL

  {
	"schema:url": "https://data.geoscience.fr/id/hydrogeounit/121AS01",
	"@type": "foaf:Document",
	"primaryTopic": "gw:GW_Aquifer", 
	"format": [
	  "application/gml+xml", "application/ld+json"
	],
	"conformsTo": "https://www.opengis.net/def/gwml2",
	"provider": "https://data.geoscience.fr"
  },

• the other approach to be mentionned is W3C ConnegP

Both approaches are not, yet, implemented on the server side so far.

=> Down to earth short term solution is to start "storing" just

"format": [
	  "application/gml+xml", "application/ld+json"
	],

with

schema:url": "https://data.geoscience.fr/id/hydrogeounit/121AS01
or
"provider": "https://data.geoscience.fr/id/hydrogeounit/"

Keeping in mind this logic will evolve into a more matrix oriented content at some point

[sgrellet]

Quick note on the why

schema:url": "https://data.geoscience.fr/id/hydrogeounit/121AS01
or
"provider": "https://data.geoscience.fr/id/hydrogeounit/"

It's easy to make QGIS remember that for a given url/URI ( here : "https://data.geoscience.fr/id/hydrogeounit/121AS01) the various representations availabe are X, Y, Z... But if the user interacts a lot with that dataset, that's a lot to store (one entry for each instance in the dataset)

As URI are often designed with a given pattern, it would be handy if the user is capable of editing what he wants QGIS to remember. For that specific example, it would be better just to store that under 'https://data.geoscience.fr/id/hydrogeounit/' the various representations available are X, Y, Z... as, for all the instances in this dataset the resolver will ask the same server (here Geoserver)

[sgrellet]

Link to a server that implements content negociation for features (not content negociation by profile yet) to test the dev See : https://github.com/INSIDE-information-systems/API4INSPIRE#more-details

[sgrellet]

For the sake of highlighting where things are moving more globally

This page provides alternate representations to the URI http://www.opengis.net/def/nil/OGC/0/unknown using the following GET parameters : used '_profile' and '_mediatype'.

For example

• http://defs.opengis.net/vocprez/object?uri=http%3A//www.opengis.net/def/nil/OGC/0/unknown&_profile=skos&_mediatype=application/ld+json
• http://defs.opengis.net/vocprez/object?uri=http%3A//www.opengis.net/def/nil/OGC/0/unknown&_profile=skos&_mediatype=application/rdf+xml

Tried using curl (seems only the encoding is forwarded but that's Work In Progress)

• curl -v -k -L -H "Accept:text/turtle" -H "profile:skos" http://www.opengis.net/def/nil/OGC/0/unknown
• curl -v -k -L -H "Accept:application/rdf+xml" -H "profile:skos" http://www.opengis.net/def/nil/OGC/0/unknown