JSON-LD

[akuckartz]

trafficstars

I am missing support for JSON-LD (and RDF and Linked Data in general).

[cportele]

We have support for JSON-LD in our ldproxy implementation of WFS 3.0, but I do not think that there is enough demand/use of JSON-LD/RDF for spatial data to include it in the Core. If there is enough interest and use of JSON-LD, I am sure there will be an extension.

On another note, WFS 3.0 is about Linked Data. See W3C/OGC Spatial Data on the Web Best Practices, chapter "Linked Data" for a discussion about this.

[akuckartz]

I have read that document but strongly disagree with the reinterpretation (weakened definition) of the term "Linked Data" expressed in it. I will have a closer look at ldproxy.

[timoruohomaki]

I totally agree that the definition is limited there and as an example also misses the point of linked data to improve semantic interoperability. There has been discussion of making a more complete best practise document on the implementation of linked data in spatial context. FYI, we are currently working on implementing UCUM (ISO 80000) as a SKOS -ontology to be the controlled vocabulary used on sensor data and CityGML. There's also national level data model work in progress that would rely on these and the first services are going live in the next few months. This is not an area of experimenting and piloting anymore.

[cportele]

06-MAY-2019 Conference call: Currently the use of JSON-LD in spatial is limited, but that may change soon. In any case, this should be in scope of an extension. Maybe SELFIE will have a look at it? Clemens/Chuck to talk to them in Leuven.

[rob-metalinkage]

To break down what is required ... JSON payloads must include a JSON-LD "@context" that defines the elements used in the JSON schema. (there is no requirement to include a JSON schema "$schema"

the context has two functions:

1. a declaration of intent - i.e. URI identifier of a context
2. source of mappings from schema elements to URIs

The context, for a payload response in JSON, identifies the payload content model - and is equivalent to the XSD schema declaration for a response. So we are not talking about anything new here, and including this statement wont break JSON in any way.

In the OGC definitions server environment I will undertake automatically generating JSON contexts for OGC published application schema - and will use content negotiation so that if you ask for the application schema as application/ld+json you will get the JSON-LD context - and can extend it further so if you ask for it as JSON you will get a JSON-schema document.

(getting JSON-LD encoding of the RDF for the model definition itself can be accessed via a named profile - i think the simplest thing is for the default to be the most directly useful form)

Please contact me if you wish to set up experiments or to publish context documents via OGC naming authority (I am also rep on the NA for HY_Features SWG and keen to align that AppSchema with use in OGC-API)

[sgrellet]

@cportele : 'Maybe SELFIE will have a look at it?' . I confirm that in SELFIE we are working on those aspects (following what ELFIE started). Elements just brought in by @rob-metalinkage are actually also related to discussions between SELFIE team and @rob-metalinkage on ontologies generated by @afeliachi to be used in OGC JSON-LD contexts. SELFIE team is also pushing hard for some OGC API - Features implementations to support JSON-LD : in PyGeoAPI (@alpha-beta-soup) and GeoServer JSON-LD community plugin (@afeliachi and myself)

[cportele]

@sgrellet - thanks. In ldproxy we have removed the old JSON-LD module. Instead we are experimenting with an option to add JSON-LD keywords (@context, @type, @id) to make the responses valid GeoJSON and JSON-LD.

[rob-metalinkage]

Cool - I think the judicious insertion of context is more useful that dumping anonymous schemas as JSON-LD - all form but no substance.

The most semantically valuable substance is not just individual schema elements but identification of the context as an interoperable set of of such definitions - and the major questions here are:

1. whether we can (and should) work with contexts identified by URIs or just inline stuff
2. whether contexts should be modular using nested '@context' or arbitrarily large flattened collations of statements from multiple sources
3. whether contexts should be "just contexts" or actually just a representation of an interoperability profile - i.e. what exactly is being identified.

In H2020 project DEMETER I will be working on the basis that context URI = an interoperability profile with many representations, and the JSON-LD representation will be a modular, cachable tree of nested contexts. This is both the most semantically explicit and flexible architecture with the greatest cachability potential.

As always, clients are going to be needed before most people will understand this.

Can we set up a specific sub-group on this topic and have some regular meetings to share and coorindate - and feed back to OGC-API, Geosemantics, OGC-NA, SELFIE, SDWIG and OAB (at a bare minimum these seem to be the stakeholders - which is probably why we havent been very coordinated so far!)

[akuckartz]

A brief comment mentioning SPARQL: https://github.com/opengeospatial/ogcapi-features/issues/367#issuecomment-618810976

[lvdbrink]

1. whether we can (and should) work with contexts identified by URIs or just inline stuff

In my opinion it would be great if we use URIs - one option would be pointing to the OGC Definitions server, right?

Can we set up a specific sub-group on this topic and have some regular meetings to share and coordinate - and feed back to OGC-API, Geosemantics, OGC-NA, SELFIE, SDWIG and OAB (at a bare minimum these seem to be the stakeholders - which is probably why we havent been very coordinated so far!)

You're welcome as a subgroup of Geosemantics if you want

[akuckartz]

https://github.com/opengeospatial/geosemantics-dwg

[situx]

Maybe our project currently performed at the Federal Agency for Cartography and Geodesy of Germany is of interest here. We are developing what we call a "SemanticWFS" which exposes FeatureTypes which have SPARQL queries as a backend. The "SemanticWFS" exposes data using the WFS API, but also using OGC API Features. A test instance is available here: https://www.i3mainz.de/projekte/bkg/semanticwfs/collections/ Github Repository: https://github.com/i3mainz/semanticwfs We offer Semantic Downlifts in various formats, one of them being TTL: Example here: https://www.i3mainz.de/projekte/bkg/semanticwfs/collections/NamedPlace/items?f=ttl

[rob-metalinkage]

i see it also supports JSONLD

https://www.i3mainz.de/projekte/bkg/semanticwfs/collections/NamedPlace/items?f=jsonld

what I am interested here in though is a pattern where contexts are re-used, so the data model has a context and the data merely references it.

This has several benefits:

1. It allows the nature of the data to be immediately determined by looking at the context (exact equivalance with dcterms:conformsTo is a matter to consider - but there are a couple of options here)
2. The context data and all the URIs can be cached
3. It is possible to have "vanilla JSON" annotated by binding existing property names to data models (the use of some sort of "base namespace" would be required here - buts thats a pretty common pattern.
4. Can use namespace prefixes to make data more readable
5. Can bind to JSON-schema as well to have more typing information available in the data

I am writing a tool to build JSON-LD contexts from OWL models using a import pattern - so if you have OWL model views of the feature types available I'd be happy to test and see if this works for you.