– DRAFT –
DXWG DCAT subgroup teleconference 01 May 2019 20:00 UTC

DaveBrowning: So, it's just 3 of us. What we want to talk about?

SimonCox: [explaining the PRs created in the last days]
… some of them are pretty trivial / editorial.
… The substantial one is https://‌github.com/‌w3c/‌dxwg/‌pull/‌909
… about spatial / temporal encoding.
… I think addressing it is useful, also because the geo community didn't address it.
… For the temporal, AndreaPerego added a DCAT-based solution. I added here an option based on existing vocabularies, in particular OWL-Time.

DaveBrowning: Those different approaches, do we need them? Which is the requirement behind it?

SimonCox: So, e.g., for another temporal-related issue - temporal resolution - we eventually opted for a DCAT-specific solution, simpler than using existing vocabularies as RDF DataCube.
… AndreaPerego took a similar approach to spatial / temporal coverage, using DCMI. The issue is that neither DCMI nor DCAT 2014 explained how to do that in practice.
… AndreaPerego, are we using the spatial-related properties only for datasets?

AndreaPerego: I think yes, but in theory they can be used on any dcat:Resource with a spatial coverage.

SimonCox: About the temporal coverage, the addition of OWL-Time is actually an alternative way of doing what can be done with dct:PeriodOfTime.

<SimonCox> ... and can support non-Gregorian calendar requirements

SimonCox: So, the issue about alternatives is to clarify how they fit different requirements.

AndreaPerego: Yes, I think this can simply done with a short explanation saying what you can do with each option (e.g., only WGS84 vs any CRS).

<SimonCox> ANd for Spatial, the WKT options allow for different CRS, while the w3cgeo soluion is fixed to WGS84

AndreaPerego: Just to mention that the proposed solutions for spatial / temporal coverage are those adopted in DCAT-AP, and addressing gaps identified in that context.

DaveBrowning: I would be in favour of having this included, as spatial / temporal is not something domain-specific.

SimonCox: AndreaPerego, I'm a bit nervous with using LOCN, because of its adoption limited to Europe.

AndreaPerego: Actually, in the originally issue, I was proposing some alternatives, one of them being the definition of a property dcat:geometry, equivalent to locn:geometry.

SimonCox: This can indeed be another option.

<SimonCox> need an example with a CRS

All: [some discussion of geometry encoding, CRS, et similia]

DaveBrowning: Coming to the status of DCAT, I think we are very close to the final version. So, the question is what we want to bring up in the next meeting as critical.

AndreaPerego: One of them is whether we want to keep or move out the alignment with LDP.

DaveBrowning: We need to finish that conversation.

<DaveBrowning> proposed: Move LDP into a separate document to preserve, but remove from ED

+1

<SimonCox> +1

<DaveBrowning> +1

Resolved: Move LDP into a separate document to preserve, but remove from ED

DaveBrowning: About what is yet to be done, we need to check the links. But are there other editorial issues to be addressed?
… I'll put an early agenda for next week, to check if we have finished or not.
… So, if the answer is yes we can go the plenary for approval.

+1 from me

<SimonCox> +1

<DaveBrowning> DaveBrowning: NOTE - Minutes of last meeting not discussed/approved

[meeting adjourned]