Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OGC Metadata Codesprint 2024 - Proposals and use cases #17

Open
ByronCinNZ opened this issue Sep 26, 2024 · 7 comments
Open

OGC Metadata Codesprint 2024 - Proposals and use cases #17

ByronCinNZ opened this issue Sep 26, 2024 · 7 comments
Labels
Codesprint OGC Metadata Codesprint Sydney 2024

Comments

@ByronCinNZ
Copy link
Collaborator

ByronCinNZ commented Sep 26, 2024

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 ByronCinNZ added the Codesprint OGC Metadata Codesprint Sydney 2024 label Sep 26, 2024
@ByronCinNZ
Copy link
Collaborator Author

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
Copy link
Collaborator

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
Copy link
Contributor

PeterParslow commented Sep 26, 2024

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

I would suggest skipping OWL and going straight to SHACL.

@christinhenzen
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Codesprint OGC Metadata Codesprint Sydney 2024
Projects
None yet
Development

No branches or pull requests

5 participants