W3C

– DRAFT –
DXWG DCAT subgroup

08 February 2022

Attendees

Present
AndreaPerego, DaveBrowning, Nobu_OGURA, riccardoAlbertoni
Regrets
-
Chair
RiccardoAlbertoni
Scribe
AndreaPerego

Meeting minutes

approve last meeting minutes

<riccardoAlbertoni> PROPOSED: approve last meeting minutes https://www.w3.org/2022/01/25-dxwgdcat-minutes

+1

<riccardoAlbertoni> +1

<DaveBrowning> +1

<Nobu_OGURA> +1

RESOLUTION: approve last meeting minutes https://www.w3.org/2022/01/25-dxwgdcat-minutes

approve agenda

+1

Nobu_OGURA: I have a few questions I would like to ask.

riccardoAlbertoni: Thanks, Nobu_OGURA. Agreed.

Nobu's presentation

Nobu_OGURA: [Introducing the Data Society Alliance - DSA]

Nobu_OGURA: DSA developed an extension to DCAT covering notions as "data jacket", "data detail", "data terms of use".

Nobu_OGURA: We are now in the process of moving to DCAT2, but there are a few things whose use is not completely clear.
… One of the them is the use of dcterms:hasPart with dcat:Catalog - semantics and cardinality not clear.
… Another one is dcat:Distribution and dcat:DataService - difference not clear.
… Third point is about dcat:CatalogRecord, especially property dcterms:conformsTo - not sure about the definition.
… Last point is about dcat:Dataset and properties related to spatial and temporal resolution - what about other kinds of resolution, e.g., for grid data?

riccardoAlbertoni: Thanks, Nobu_OGURA.

<riccardoAlbertoni> https://github.com/w3c/dxwg

AndreaPerego: About the last point, we included only those types of resolutions since they are relevant across domains. Domain-specific types of resolution are supposed to be addressed by specific DCAT profiles / extensions. E.g., GeoDCAT-AP extends DCAT by supporting the different types of spatial resolution supported in ISO 19115.

Pending PRs

<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/1437

<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/1437

riccardoAlbertoni: The issue is about the duplication of dcat:accessURL and dcat:downloadURL in some examples.
… The discussion however also introduced other interesting aspects related to profiles.
… But, IMO, these aspects should not be part of the DCAT spec - they should be addressed in profiles.
… We should not further restrict the use of properties.

riccardoAlbertoni: Do you agree to close this issue via the related PR, and not further restrict DCAT?

+1

<DaveBrowning> +1

<riccardoAlbertoni> +1

RESOLUTION: close issue https://github.com/w3c/dxwg/issues/1437

riccardoAlbertoni: We need to finalise versioning and dataset series.

<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/1442

riccardoAlbertoni: There's a PR on versioning

<riccardoAlbertoni> https://github.com/w3c/dxwg/pull/1451

<riccardoAlbertoni> “The version indicator (name or identifier) of a resource.”

riccardoAlbertoni: The issue is about making it explicit that we support both numbers and text as a version indicator.

riccardoAlbertoni: Some of the comments were suggesting not using "version" in the definition.
… IMO, using "revision" instead of "version" may limit the ontological commitment.
… The problem is that the explicit use of the notion of "revision" in the normative part would restrict the use the versioning properties.

<riccardoAlbertoni> "dcat:version = a number or text that identifies a particular revision of the resource"

<riccardoAlbertoni> proposed: Let’s keep “version” as The use of the world version in the normative part leave open to other kind of versions than revision. And we do not want to restrict the ontological commitment without evidence that version = revision at this stage.

DaveBrowning: I agree to keep the two aspects separated - the explicit support to text in version numbers and the use of "revision" instead of "version".

<riccardoAlbertoni> +1

<DaveBrowning> +1

<Nobu_OGURA> +1

+1

RESOLUTION: Let’s keep “version” as the use of the word version in the normative part leaves open to other kinds of versions than revisions.. And we do not want to restrict the ontological commitment without full evidence that version = revision at this stage.

<riccardoAlbertoni> Dataset series and inheritance issue #1273

<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/1273

riccardoAlbertoni: This is about possible inheritance of properties and their values in dataset series.
… Annette raises the issue of updating existing metadata, which may result in inconsistent or outdated records.
… I wonder whether the problem here is that there is a use case where datasets in a series are maintained by different curators / organizations.

AndreaPerego: Actually, the purpose of the section was mainly to give some indication of what the metadata of a series should be based upon those of its datasets.
… The idea was not to require that dataset series metadata be updated.

<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/1395

riccardoAlbertoni: There is also another issue about the fact that dcat:DatasetSeries is a subclass of dcat:Dataset ^^

<riccardoAlbertoni> proposal: close issue 1273 as we think no other inheritance constraints are need

+1

<riccardoAlbertoni> +1

<DaveBrowning> +1

<Nobu_OGURA> +1

RESOLUTION: close issue 1273 as we think no other inheritance constraints are needed

AOB?

[meeting adjourned]

<riccardoAlbertoni> s/. And we do not want to restrict the ontological commitment without evidence that version = revision at this stage./And we do not want to restrict the ontological commitment without full evidence that version = revision at this stage.

<riccardoAlbertoni> s/And we do not want to restrict the ontological commitment without evidence that version = revision at this stage./And we do not want to restrict the ontological commitment without full evidence that version = revision at this stage.

Summary of resolutions

  1. approve last meeting minutes https://www.w3.org/2022/01/25-dxwgdcat-minutes
  2. close issue https://github.com/w3c/dxwg/issues/1437
  3. Let’s keep “version” as the use of the word version in the normative part leaves open to other kinds of versions than revisions.. And we do not want to restrict the ontological commitment without full evidence that version = revision at this stage.
  4. close issue 1273 as we think no other inheritance constraints are needed
Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: s/^^//

Succeeded: s/Let’s keep “version” as The/proposed: Let’s keep “version” as The/

Succeeded: s/costraints/inheritance constraints/

Succeeded: s/resolve/resolved

Succeeded: s/are need/are needed/

Succeeded: s/are need/are needed/

Succeeded: s/neededed/needed

Succeeded: s/Let’s keep “version” as The use of the world version in the normative part leave open to other kind of versions than revision/Let’s keep “version” as the use of the word version in the normative part leaves open to other kinds of versions than revisions.

Failed: s/. And we do not want to restrict the ontological commitment without evidence that version = revision at this stage./And we do not want to restrict the ontological commitment without full evidence that version = revision at this stage.

Failed: s/And we do not want to restrict the ontological commitment without evidence that version = revision at this stage./And we do not want to restrict the ontological commitment without full evidence that version = revision at this stage.

Succeeded: s/And we do not want to restrict the ontological commitment without evidence that version = revision at this stage./And we do not want to restrict the ontological commitment without full evidence that version = revision at this stage.