Meeting minutes
approve last meeting minutes
<riccardoAlbertoni> PROPOSED: approve last meeting minutes https://
+1
<riccardoAlbertoni> +1
<DaveBrowning> +1
<Nobu_OGURA> +1
RESOLUTION: approve last meeting minutes https://
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://
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://
<riccardoAlbertoni> https://
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://
riccardoAlbertoni: We need to finalise versioning and dataset series.
<riccardoAlbertoni> https://
riccardoAlbertoni: There's a PR on versioning
<riccardoAlbertoni> https://
<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://
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://
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.