Skip to content

OGC GeoDCAT SWG meeting held 20231102

Byron Cochrane edited this page Aug 1, 2024 · 1 revision

General discussion: @ Need to confirming the bi-weekly meetings for the rest of the year: Thursdays should be ok. Timing of the agenda is incorrect due to changes in Winter/Summer time >> This time seems to be ok @send out another email invite to the list to see if this time is suitable. RA - It is not particularly good for the America's and this may be the group that should join. e.g., Image Matters - also US Fish & Wildlife who are using DCAT so they may also be interested. @ Alternate timezones can be tricky but perhaps split the meeting time for America's - Rob A. may run those at another time if there is interest. DV – Those registered may not wish to particpate directly but they did want to pay attention to updates. Type of information that needs to be collected from different parts of the world so that this paper can be updated to reflect what changes could be made to the current version of DCAT to improve the geospatial aspect The collection of information for GeoDCAT-AP for a best practice document was started some time ago (2019) but it was decided at the time to make it a discussion paper in anticipation of becoming a OGC standard.

What is described in the paper is now old. Taken from existing European projects at the time. The slide shows how the information was gathered in the paper. This is a good place to begin but it will need to be adapted. [See slide] Title: Best Practice Details: Place Organisations involved Status (test bed, production, etc) Contact person URL to the materials Focus area of 5.3

input/ harvesting Publishing Publishing as RDF Information mapping Other fields included description of Best Practice approach: workflow or tooling results / issues encountered [a good example was given at the last OGC meeting, also described in testing] Conclusions were also documented What may be missing: • Challenges to implementation or testing • Implementation examples from around the world DV - where is the template going to live so that people can update with their information? DV - should there be links on this site to any current tooling that have been used for implementation? RA - we need to work with the current AP version and remove the European only requirements and THEN start with a basic Geo-DCAT of which Geo-DCATAP will be a profile of this. https://github.com/opengeospatial/GeoDCAT-SWG/blob/main/definition/geodcat-ap-geosubset.ttl DV - the thought at the time that the GeoDCAT-AP was the one that everyone was going to use. For best practice I agree that this should be a broader look at the standard RA – I have set it up so that we can do regression tests to check that Geo-DCAT AP is a true profile of the generalised Geo-DCAT. This would be supported by OGC. Formally describing the profile which will include a movement towards the best practice that is tested along the way. Schema’s need to match the best practice. Binding of DCAT to OGC records to match the semantic models. This way OGC-APIs will work with Geo-DCAT. BC – I like the idea of identifying existing Geo-DCAT from the AP but DCAT has progressed so how do we modernise the existing AP whilst still making Geo-DCAT aligned with the current version of D-CAT 2.0 and 3.0. RA – OGC will not decide what the Geo-DCAT elements will look like but they will support the alignment of the schemas, documentation, testing and versions. DV – previous harvesting examples included harvesting from portals that had INSPIRE profiles of 19115 and just vanilla 19115. But these examples may be needed to explain the issues RA - https://github.com/ogcincubator/geodcat-ogcapi-records/tree/master/_sources/geodcat/examples PP – What do we drop into the directory for you? Background implementation instances/examples to check that our version of GeoDCAT meet the profile –> documents, csv files with mappings, and other materials. DV – I have the impression that we need to give guidance on what is delivered. I will find one example to start the conversation to provide a template for others to submit their examples and best practices. (so they see how to do it). We need the description of what is going on to support the technical implementation. RA – does not think there are current good examples. But perhaps collect information but then look at them and then decide if there is a best practice in there. BC – I would like to start with a user story approach. Why they chose GeoDCAT and why it was implemented the way it was. Then the issues they encountered. And other business requirements. RA - human readable profiles, any machine-readable version, one or more simple examples as standalone files would be great. Particularly which part they are using. RA – Perhaps create a directory with your own README file so that you submit at the level of detail you can DV – call it Examples of Implementation (not best practice), ask for documentation or mappings etc, ask for links to any implementations etc. Then we can select a few examples for testing. Good to understand what is out there and for them to understand there are better ways to implement. Also from the examples process, we could then determine a Best Practice at a later stage. @ provide a template for acquiring examples on GitHub so that it is collected in a similar way RA - https://project-open-data.cio.gov/v1.1/schema/ is a US Government example. DV – will ask the European implementers for their documentation. Also there will be a conference for INSPIRE and those that present. DV – Another example could come from OGC-Euorpean-DCAT consortium MS – ask Nick for his example for Aus-GeoDCAT to include in this work RA - https://resources.data.gov/schemas/dcat-us/v1.1/schema/catalog.jsonld is an example of how US Gov is mapping to GeoDCAT @RA will determine what maps to DCAT and what Geo types don’t map well which will then become GeoDCAT. PP – talked about the sharing the UK experience for the DCAT and then the Geo extensions that they thought were important. At the moment it is just the basic core (data quality measures) and not the spatial yet. RA – there are some sub-profiles that could be looked at. Eg statistical datacube, provenance, observations. There could be a lightweight CORE Geo-DCAT and then their domain profiles. DV - Before next meeting can we collect some examples so that we can discuss what the template will look like to ask further questions. ACTIONS

Send out meeting invite to confirm the time and dates for the ongoing meetings. Seek information from the mailing list about any members that are unable to attend due to the time of day/night and ask if they wish to be part of the meeting if it was held at another time (this relates to Rob A.’s offer to run an alternative time at some point – clear with Rob first) GeoDCAT-* examples to be collected from the SWG and to be placed in https://github.com/ogcincubator/geodcat-ogcapi-records/tree/master/_sources/geodcat. They will comprise: a. Existing business cases and/or requirements for implementation b. Documentation for users of implementation with any issues that arose with GeoDCAT-* c. *.csv mappings of metadata d. Implementation schemas e. ? Group will create a lock-step template for people outside the SWG to submit examples based on what the SWG comes up with in 3. In general, the scope of the SWG work will be to: create a core OGC GeoDCAT standard/profile of DCAT v2 and 3 demonstrate programmatically how the core supports the existing profile GeoDCAT-AP seek to document a core OGC GeoDCAT and how profiles can be tested via OGC processes documentation of Best Practice

Clone this wiki locally