OGC Metadata Codesprint 2024 - Proposals and use cases

[ByronCinNZ]

Please use this space to submit ideas for issues that could be addressed during the OGC Metadata Codesprint, which will be held from November 18 to 19, 2024 Sydney Aus and online.

Alternatively, create new issue for your codesprint idea and tag it with Codespint.

Participants are encouraged to collaborate and comment on proposals.

[ByronCinNZ]

Proposal - Can Metadata Standards Play Nicely?

The idea is to determine and demonstrate where and when different standards (namely STAC, OGC API records, ISO 19115, and GeoDCAT) can work in tandem to provide the most relevant information to the right users at the right time. The goal is to create a demonstration where the strengths of each are highlighted while working in tandem.

[rob-metalinkage]

OGC will provide an open source framework for testing mappings between standards, using test case examples covering Records, STAC and DCAT. Codesprint participants would be able to extend this to XML based metadata standards such as ISO 19115, in a way that is extensible to various profiles in use. This could leverage skills in any or all of coding, datamodelling, metadata standards or application domain requirements.

[PeterParslow]

Proposal: what's the future for ISO 19115?

Background: roughly half the ISO/TC 211 members consider that ISO 19115-1:2014 should be revised and yet a lot of areas have not yet moved from the earlier version. There is a lot of discussion e.g. in Europe about moving from ISO 19115:2003 to DCAT instead.

I would like to canvas views on what could be useful for ISO/TC 211 to do, for example:

• a formal document on how to map ISO 19115-1 to DCAT
• a new version of ISO 19115-1 restructured using the DCAT terms and structure
• in both cases, something about aligning the encoding of ISO 19115-1 with one or more encodings of DCAT
• almost a separate request: some would like to see an RDF/XML and/or OWL "encoding" of ISO 19115-1; how official should that be?

I'm sure I've not thought of all the "possibly useful futures"; I hope the assembled brains will help!

[rob-metalinkage]

Proposal: what's the future for ISO 19115?

Background: roughly half the ISO/TC 211 members consider that ISO 19115-1:2014 should be revised and yet a lot of areas have not yet moved from the earlier version. There is a lot of discussion e.g. in Europe about moving from ISO 19115:2003 to DCAT instead.

I would like to canvas views on what could be useful for ISO/TC 211 to do, for example:

• a formal document on how to map ISO 19115-1 to DCAT
• a new version of ISO 19115-1 restructured using the DCAT terms and structure
• in both cases, something about aligning the encoding of ISO 19115-1 with one or more encodings of DCAT
• almost a separate request: some would like to see an RDF/XML and/or OWL "encoding" of ISO 19115-1; how official should that be?

I'm sure I've not thought of all the "possibly useful futures"; I hope the assembled brains will help!

Hi Peter,

in terms of a specific "code sprint" activity, we could look to define and exercise the "mapping" - this could be done several ways and the GeoDCAT Building Blocks can be used to execute, test and publish these mappings. Five options I can immediately see:

1. XML->JSON using existing libraries and JSON-LD uplift (often this needs an intermediate transform)
2. 19115 UML -> JSON schema and OWL using Shapechange, and JSON-LD uplift (bonus marks to make shapechencge generate the JSON-LD mapping) - and transforms from 19115 OWL to GeoDCAT.
3. Use existing transform languages and libraries designed for relational->RDF mapping such as R2RML
4. custom scripts taking a mapping table and generating or incorporating custom translation code per element
5. Take a 19115 -> OGC Records mapping and use the Records->DCAT mapping under development

Note that option 4 could be used to generate the transforms for 1,2 or 5. Option 5 will be most OGC API friendly solution.

[PeterParslow]

Thanks Rob; I was thinking more to have a short 'think & talk' break where people just give their views on what they'd like to see improve/change in ISO 19115. The revision project in TC 211 hasn't even started yet, so I we're not ready for any hands on stuff.
Of course if people's ideas of what to change are based on practical work they've done, that's even better. One example could be item 3 - I have heard others say they'd like to see an "official" RDF (even specifically, OWL) representation of ISO 19115. Question: would that actually be more beneficial as an "official" ISO/TC 211 DCAT, then represented in RDF?

The activities you list would all sit in the area of using the current ISO 19115-1:2014 (with accompanying XML spec 19115-3 & soon to have JSON spec 19115-4), or even the old ISO 19115:2003/ISO 19139:2006 (as still used in Europe quite a lot). Paul Jansen is leading that second project, which has involved some of 1 & 2 in your list.

5 looks a useful input to the upcoming ISO 19115-1:2014 revision project.

[dr-shorthair]

I would suggest skipping OWL and going straight to SHACL.

[christinhenzen]

Hi all,

We would like to submit a proposal on FAIRness evaluation & GeoDCAT:

Evaluating the FAIRness of geospatial data - Extending the F-UJI tool for GeoDCAT

Evaluating the FAIRness of geospatial data requires specific adoptions of the FAIR principles and related evaluation tools. Taking F-UJI (https://github.com/pangaea-data-publisher/fuji), the well-known open-source evaluation tool, as a software project for our use case, we consider the following GeoDCAT extensions for further brainstorming:

• Findable: Evaluate spatial information as defined in GeoDCAT, e.g., using the bounding box
• Accessible: Check if the metadata contains information about a geospatial Web service, e.g., WMS or WFS
• Interoperable: Evaluate the proper use of geospatial standards/specifications, e.g., CRS
• Reusability: Evaluate spatial reference system, spatial resolution, and spatial data formats, e.g. GeoJSON

We intend to share the developed extension with the Earth System Sciences community as open-source, facilitating its reuse in geodata portals/catalogues, such as the European data portal or the NFDI4Earth Services Knowledge Hub or OneStop4All.

[akuegeler]

Proposal: GeoDCAT response for OGC API Records
How about implementing a GeoDCAT response for OGC API Records?
A good place to start should be Rob’s GeoDCAT mapping for OGC API Records. @rob-metalinkage do you think this is doable/a good idea?

We could use pygeoapi's CSW facade as a starting point and transform the ISO19115/ISO19139 metadata from a CSW to GeoDCAT.

Your thoughts on this would be greatly appreciated (especially as we have only limited knowledge on OGC API Records).

[PeterParslow]

Proposal: GeoDCAT response for OGC API Records How about implementing a GeoDCAT response for OGC API Records? A good place to start should be Rob’s GeoDCAT mapping for OGC API Records. @rob-metalinkage do you think this is doable/a good idea?

We could use pygeoapi's CSW facade as a starting point and transform the ISO19115/ISO19139 metadata from a CSW to GeoDCAT.

Your thoughts on this would be greatly appreciated (especially as we have only limited knowledge on OGC API Records).

Does the GeoNetwork (draft?) API Records implementation provide an alternative starting point? It already provides an OGC API Records DCAT output for records that are "natively" stored as ISO 19139 (or presumably other forms). See example (with unattractive GUI layout!) at https://osmetadata.astuntechnology.com/geonetwork/api/collections/main/items (use ?f=dcat or click link)

[rob-metalinkage]

Review https://docs.ogc.org/bp/17-084r1/17-084r1.html and explore how this overlaps with Records or other options for JSON encoding. (Thanks Uwe)

[PalmJanssen]

Hi All,

ISO TC 211 - working group 7 - Information Communities, is developing a JSON implementation of the 19115 metadata-standard, the 19115-4, Geographic information — Metadata —
Part 4: JSON schema implementation of metadata fundamentals.

We are looking for help on creating a GeoJSON schema and want to put that into the Code-sprint

Our approach is the following:

• 19115-1 and 19157-1 (data quality) are in scope
• encoding will be in GeoJSON
• automated generation from uml to GeoJSON schema is possible, but will create an over-complex JSON schema which will be not fit for purpose
• a comprehensive XML 'real life' dataset is created and converted to a GeoJSON preferred encoding (this work is done)
• the GeoJSON example dataset is a subset (profile) of 19115-1 and 19157-1, but is considered to cover the essential part
• the GeoJSON example dataset is considered as the requirements that are set for the GeoJSON schema (to be developed)
• on the basis of this GeoJSON dataset and the conceptual UML model a GeoJSON schema needs to be generated.
• a first run of creating a GeoJSON schema from the conceptual UML is available but this needs to be reworked to fit the GeoJSON exmaple.

The goal set and work to be done is reworking the first concept of the GeoJSON schema on the basis of the agreed GeoJSON data example.

What is needed:

• JSON/GeoJSON expertise
• 19115 metadata domain knowledge
• hands on

[rob-metalinkage]

Hi All,

ISO TC 211 - working group 7 - Information Communities, is developing a JSON implementation of the 19115 metadata-standard, the 19115-4, Geographic information — Metadata — Part 4: JSON schema implementation of metadata fundamentals.

We are looking for help on creating a GeoJSON schema and want to put that into the Code-sprint

Our approach is the following:

• 19115-1 and 19157-1 (data quality) are in scope
• encoding will be in GeoJSON
• automated generation from uml to GeoJSON schema is possible, but will create an over-complex JSON schema which will be not fit for purpose
• a comprehensive XML 'real life' dataset is created and converted to a GeoJSON preferred encoding (this work is done)
• the GeoJSON example dataset is a subset (profile) of 19115-1 and 19157-1, but is considered to cover the essential part
• the GeoJSON example dataset is considered as the requirements that are set for the GeoJSON schema (to be developed)
• on the basis of this GeoJSON dataset and the conceptual UML model a GeoJSON schema needs to be generated.
• a first run of creating a GeoJSON schema from the conceptual UML is available but this needs to be reworked to fit the GeoJSON exmaple.

The goal set and work to be done is reworking the first concept of the GeoJSON schema on the basis of the agreed GeoJSON data example.

What is needed:

• JSON/GeoJSON expertise
• 19115 metadata domain knowledge
• hands on

Note I have moved this to a new issue to allow targetted discussions.

[uvoges]

A valuable input for a specification of a JSON(+LD) Encoding of the ISO metadata could be the OGC BP https://docs.ogc.org/bp/17-084r1/17-084r1.html
Here we defined a GeoJSON and JSON-LD encoding for metadata for Earth Observation (EO) collections (dataset series).It mainly encodes ISO19115 with some extensions for the Earth Observation Domain e.g. Satellite/Platform, Instrument,... which were integrated from ISO19115-2.

A convergence of the proposed JSON-LD mapping with GeoDCAT-AP [OR15] was a further intention.

The GeoJSON encoding is defined as a compaction through a normative context, of the proposed JSON-LD encoding, with some extensions.

JSON is human readable and easily parseable. However, the BP is based on a normative JSON-LD context which allows each property to be explicitly defined as a URI. Furthermore, the JSON encoding is defined using JSON Schema which allows validation of instances against these schemas.
The specification defines a GeoJSON-based serialization syntax for Earth Observation Collection Metadata that conforms to a subset of [NR13] syntax constraints but does not require JSON-LD processing

JSON-LD context /compaction
While expansion removes context from a given input, compaction’s primary function is to perform the opposite operation: to express a given input according to a particular context. Compaction applies a context that specifically tailors the way information is expressed for a particular person or application. This simplifies applications that consume JSON or JSON-LD by expressing the data in application-specific terms, and it makes the data easier to read by humans [OR4].
JSON-LD uses the special @context property to define the processing context. The value of the @context property is defined by the JSON-LD specification. Implementations producing EO Collection metadata documents should include a @context property with a value that includes a reference to the normative JSON-LD @context definition here using the URL “https://www.opengis.net/spec/eoc-geojson/1.0
JSON-LD 1.1 [OR21] aware clients can apply a JSON-LD 1.1 @context to interpret the GeoJSON encoding as JSON-LD.
{
"@context": #http://bp.schemas.opengis.net/17-084r1/eoc-geojson/1.0/eoc-geojson.jsonld""
}
A context is a set of rules for interpreting a JSON-LD document as specified in the section “The Context” of the JSON-LD specification [NR13]
While expansion removes context from a given input, compaction’s primary function is to perform the opposite operation: to express a given input according to a particular context. Compaction applies a context that specifically tailors the way information is expressed for a particular person or application. This simplifies applications that consume JSON or JSON-LD by expressing the data in application-specific terms, and it makes the data easier to read by humans [OR4].The proposed context can be found here: http://bp.schemas.opengis.net/17-084r1/eoc-geojson/1.0/eoc-geojson.jsonld"

[NR13]A JSON-based Serialisation for Linked Data, W3C Recommendation, 2014, http://www.w3.org/TR/json-ld/
[OR4][4] JSON-LD 1.0 Processing Algorithms and API, W3C Recommendation 16 January 2014, https://www.w3.org/TR/json-ld-api/
[OR15]: GeoDCAT-AP: A geospatial extension to DCAT application profiles for data portals in Europe, Version 1.0.1, 02/08/2016, https://semiceu.github.io/GeoDCAT-AP/releases/1.0.1/geodcat-ap_1.0.1.pdf

for more details, examples etc refer to https://docs.ogc.org/bp/17-084r1/17-084r1.html

You can also experiment (compaction/expansion,...) with the BP examples in the json-ld playground: https://json-ld.org/playground/