– DRAFT –
DXWG DCAT subgroup

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

accept last meeting minutes

<alejandra> +0

+1

<riccardoAlbertoni> +1

<Nobu_OGURA> +1

RESOLUTION: approve last meeting minutes https://www.w3.org/2022/02/22-dxwgdcat-minutes

approve agenda

Responding to one of the Nobu's questions

riccardoAlbertoni: Let's look at Nobu_OGURA 's question on the difference between dcat:Distribution vs dcat:DataService

riccardoAlbertoni: (explaining what a dcat:Distribution and a dcat:DataService are about)

<riccardoAlbertoni> https://w3c.github.io/dxwg/dcat/#ex-access-service

riccardoAlbertoni: It may be worth looking at the example in the spec ^^

<alejandra> AndreaPerego: I'll give the historical perspective...

<alejandra> ... multiple distributions depending on the format

<alejandra> ... when DCAT started to be used in multiple domains and more widely, the data wasn't available as downloadable files but through APIs or web services

<alejandra> ... people were expecting to get the data directly, instead for data behind an API or a web service, the accessURL was the URL of the API or web service endpoint

<alejandra> ... you can get an error in some cases, you have not specified the required parameters to get the data, so there was some work done in some application profiles of DCAT to extend the distribution indicating that it wasn't a downloadable file

<alejandra> ... but a web service; in addition, to make it possible to automitise the access to the data, API or service protocol

<alejandra> ... specially when built upon standards, feature service, etc

<alejandra> ... then the client was able to understand

<alejandra> ... additional requirement to have a separate data service class came later

alejandra: I would like to ask Nobu_OGURA if the specification wasn't clear enough about the difference and purpose of dcat:Distribution and dcat:DataService.
… Do you think there's anything we can improve?

Nobu_OGURA: I can say that, working on the Japanese translation of DCAT, these aspects are not completely clear.

riccardoAlbertoni: I think also the problem is that we have change a few things in DCAT3, also to improve the explanations. Maybe this can help.

<alejandra> AndreaPerego: another place to get help is in the change log

<alejandra> ... this also gives an explanation on why a class was added or modified

<alejandra> ... it also points to the issue where the discussion happened, even though there are many issues and the discussion is long

Pull Request PR #1461

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

<alejandra> relates to this issue: https://github.com/w3c/dxwg/issues/1335

riccardoAlbertoni: This is the PR to add the inverse of dcat:inSeries.
… Are there any issues to merge it?

AndreaPerego: No particular issues, but not clear to me if there are still objections.

alejandra: I'll put a comment on the PR.

riccardoAlbertoni: I think most of the objections were solved when we adopted the PROV approach for inverse properties.
… About the naming, we can consider other options, if you have them.

issue #1409

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

<alejandra> AndreaPerego: the issue is a comment from outside the group and they are raising an issue concerning datasets that are grouped into series but are also versions

<alejandra> ... replied to them showing how to combine series and versions

<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/1409#issuecomment-1051236648

<alejandra> riccardoAlbertoni: I wouldn't revise the example but add a link

riccardoAlbertoni: I think it would be worth to link to the example in the specification.

alejandra: I think it may be a good idea to add the example in the spec, to complement the existing one.

proposed: We add https://github.com/w3c/dxwg/issues/1409#issuecomment-1051236648 to the guidance section on dataset series

<alejandra> +1

<riccardoAlbertoni> +1

+1

<Nobu_OGURA> +1

RESOLUTION: We add https://github.com/w3c/dxwg/issues/1409#issuecomment-1051236648 to the guidance section on dataset series

PR 1472

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

riccardoAlbertoni: It's about updating the DCAT class diagram based on the last changes.
… In particular: new properties were added, and inverse properties were removed from the diagram.

riccardoAlbertoni: AndreaPerego was also proposing to consider removing the cardinality restrictions.
… There restrictions are non-normative, and are just there to provide some guidance.

riccardoAlbertoni: I'm personally a bit concerned in removing them, as people may rely on them.

alejandra: I would favour to keep the cardinality, making it clear they are non-normative.
… For implementers, the more information is provided, the better.

riccardoAlbertoni: There's a note about the fact that these cardinalities are non-normative - as well as the whole diagram.

Nobu_OGURA: I have the same opinion. Better keep the cardinality.

DCAT diagram: https://www.w3.org/TR/vocab-dcat-3/images/dcat-all-attributes.svg

AndreaPerego: I think we don't need to explicitly specify 0..* cardinality, as this is the default one.
… Also, the only cardinality restriction we have in the RDF definition is on foaf:primaryTopic.

alejandra: Probably the best thing is to discuss cardinality in a primer.
… So, I think we should remove all the restrictions that are not in the RDF definition.

Nobu_OGURA: I agree.

alejandra: About the one on dcat:inSeries, as it is a new thing, probably we should not specify it.

<Nobu_OGURA> +1

proposed: We remove all the cardinality constraints from the diagram when they are not in the RDF definition

<riccardoAlbertoni> +1

<alejandra> +1

<Nobu_OGURA> +1

+1

RESOLUTION: We remove all the cardinality constraints from the diagram when they are not in the RDF definition

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

Issue 1443

riccardoAlbertoni: We discussed this issue during the last meeting, and decided to not to change the names of properties dcat:prev etc.
… Annette however pointed out that any ordered collection is a series.

<riccardoAlbertoni> The first resource in a series of resources, to which the current resource belongs.

riccardoAlbertoni: So, I wonder whether we should revise the definition into "The first resource in a series of resources, to which the current resource belongs."

<alejandra> https://w3c.github.io/dxwg/dcat/#Property:resource_previous

<alejandra> https://w3c.github.io/dxwg/dcat/#Property:resource_first

alejandra: Not clear if changing "ordered collection" into "series" will solve the problem, as they are synonyms.

riccardoAlbertoni: This way we can change the property names.

<alejandra> AndreaPerego: understood the comment in the other way around

<alejandra> ... the properties are defined as subproperties

<alejandra> ... for ordered collection of resources

<alejandra> ... we are reusing properties that can be seamlessly integrated in HTTP headers (they come from IANA)

<alejandra> ... we are linking to standard practice by using these names

AndreaPerego: Changing the names will break the relationship with the IANA relation types these properties are meant to be linked to.

alejandra: I think it is not confusing to keep the names. We should just add more details in the description.

riccardoAlbertoni: About the definitions, probably we should drop "series" as it is a synonym of "ordered collection".

[meeting adjourned]