DXWG DCAT subgroup teleconference

31 January 2018

Meeting Minutes

<SimonCox> scribe?

<SimonCox> https://‌www.w3.org/‌2008/‌04/‌scribe.html

meeting agenda

<SimonCox> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Meetings:DCAT-Telecon2018.01.31

SimonCox: wants to check if everyone is OK with the items on the agenda proposed by him

<alejandra> there was an addition from Andrea

SimonCox: silent approval on the agenda

<SimonCox> https://‌www.w3.org/‌2018/‌01/‌24-dxwgdcat-minutes

2. Approve minutes from last meeting

<RiccardoAlbertoni_> +1

<SimonCox> 0


<DaveBrowning> +1

<alejandra> +1 (after adding Simon regret's)

<SimonCox> add regrets from SImon to last week's minutes ...

<Makx> 0 (wasn't there)

<PWinstanley> +1

SimonCox: there was an implicit action on everyone regarding the revision of tags on the issues on GitHub

SimonCox: I have revised the tags on a couple of issues

SimonCox: the tags on the issues were inherited from the use cases in the UCR document, not from the requirements. Hence, the need for revising them.

PWinstanley: the other sub-groups are looking at their tags too, and so we should harmonise at some point

NickolasCar and alejandra: have changed some tags and made corresponding comments on the issues

SimonCox: There is a risk of loosing traceability. At the same time, I am concerned about the processing getting too heavy.

<Zakim> alejandra, you wanted to make a proposal about the labels

Alejandra: I propose to never remove tags that correspond to the classifiation of the requirements, but tags inherited from the use cases could be removed.

<SimonCox> Proposed: ok to remove labels that were only inherited from UCs

<alejandra> and if someone has an objection, they can discuss on the issue

<SimonCox> +1

<DaveBrowning> +1

<alejandra> +1

<RiccardoAlbertoni_> +1

<AndreaPerego> +1

<PWinstanley> +1


<Makx> +1

<arminhaller> +1

Resolved: ok to remove labels that were only inherited from UCs

<RiccardoAlbertoni_> yes

<PWinstanley> no progress yet

<PWinstanley> ... for me

<DaveBrowning> Will get it done this week

<arminhaller> had some issues around the process, there weren't any to remove, but maybe some to add, but now the process is clear

<RiccardoAlbertoni_> https://‌docs.google.com/‌spreadsheets/‌d/‌1Rd5bR3lem6gsurR70e6oduuQb8VoQY2-AoBeqHKn9Ls/‌edit#gid=0

SimonCox: In the previous meeting Arminhaller, PWinstanley, and RiccardoAlbertoni_ agreed to each look at a number of issues and review them.

4.2 Review DCAT requirements

<DaveBrowning> a/PWinstanley/PWinstanley, DaveBrowning, /

<alejandra> Identification: https://‌github.com/‌w3c/‌dxwg/‌labels/‌identification

RiccardoAlbertoni_: will submit his proposals for relabelling via the GitHub issues

SimonCox: brings up the agenda point: Associate requirements with existing DCAT classes or properties, where possible

JaroslavPullmann: proposes that the relevant dcat terms become tags in the GitHub issue tracker

<arminhaller> +1

<alejandra> +1

<RiccardoAlbertoni_> +1

<SimonCox> +1

<PWinstanley> +1


<DaveBrowning> +1

<Makx> +1

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌labels

<alejandra> I can do that

Resolved: the relevant dcat terms will be used as tags in the GitHub issue tracker

DaveBrowning: Agrees that a tag for issues for which the related dcat term is unclear or inexistent can be invented later

AndreaPerego: points out that it some cases, the resolution of an issue can be not to change the current DCAT vocabulary

SimonCox: Refers to the use of requests related to issues on github

4.1 Methodology for DCAT revision: principles

<alejandra> I created the labels for all the classes referenced in the DCAT vocabulary (https://‌www.w3.org/‌TR/‌vocab-dcat/): https://‌github.com/‌w3c/‌dxwg/‌labels

<alejandra> foaf:Person and foaf:Organization

SimonCox: The original design principles about how to construct the DCAT vocabulary, included strong dependencies with DC-TERMS and less strong on SKOS, and weaker on FOAF. No other vocubularies.

<alejandra> just adding to the minutes what I said before: last week I shared my screen and we went through Github looking at the issues, labels, Pull Request and review process

<alejandra> we agreed that the Pull Request needs further discussion

SimonCox: There is no relationship with PROV in the current DCAT, now there is an opportunity (or risk) to satisfy some of the requirements with a more formal alignment with PROV.

<PWinstanley> +1 to Nic's endurant/perdurant comment

<arminhaller> +1 that we need the explicit distinction of entities and activities in dcat

NicholasCar: From his experience this would not cause problems. It may be needed to state explicitly that a dcat:Dataset is not a temporal thing.

<alejandra> +1 to the comment and there are requirements related to the temporal aspects

<SimonCox> also see discussion here: https://‌github.com/‌w3c/‌dxwg/‌pull/‌94

<SimonCox> AndreaPerego: what does QB do relating to DCAT/PROV ?

AndreaPerego: He is unsure to explicitly include subclassing in DCAT. We could followg the approach taken in RDF-DataCube, where no sub-classing of prov:Entity is needed.

AndreaPerego: One of the successes of DCAT is that its semantics were loose. Not binding dcat with strong axioms makes it more broadly usable.

<alejandra> +1

NicholasCar: Reasoning is not being used much (e.g. domain/range inference). Nonetheless it is still useful behind the scene. Also the way PROV works can be beneficial to DCAT.

SimonCox: I hear both sides: not tying things down on the other hand sub-classing from prov:Entity might even not be noticed by people not caring about inference.

SimonCox: Nonetheless, there already are domain and range restrictions in DCAT (e.g. via DC-TERMS); so the current DCAT is not entirely innocent in this regard.

ArminHaller: sub-classing and inverse properties is actually easier to handle than domain/range

AndreaPerego: I agree there already are domain/range restrictions. And we already have problems with it. For example, dcat:contactPoint is linked to vCard:Kind, which cannot be linked directly to an organisation.

AndreaPerego: rather than using OWL, we could use other means such as SHACL

SimonCox: happy to have had some time to open this discussion

<NicholasCar> Use of SHACL would introduce further commitment, not just to an ontology but to an ontology+system

<AndreaPerego> Agreed. But this might be required to ensure a consistent use of PROV and facilitate interoperability.

<Zakim> AndreaPerego, you wanted to ask if we can briefly discuss this comment of mine: https://‌github.com/‌w3c/‌dxwg/‌issues/‌76#issuecomment-359124922

SimonCox: invites everyone to go through the issues on GitHub in the coming week

AndreaPerego: brings up the point on relaxing the range restriction on dcat:contactPoint

SimonCox: suggests AndreaPerego to create a pull request for this

<RiccardoAlbertoni_> thanks, bye

<AndreaPerego> Bye!

<Jaroslav_Pullmann> bye

<alejandra> I suggested to split the issue into more granular issues

<alejandra> I'm referring to the issue: https://‌github.com/‌w3c/‌dxwg/‌issues/‌76

<alejandra> there could be a more specific issue for the agent roles

<AndreaPerego> Agreed, alejandra.

<alejandra> thanks - wanted to make sure it is in the minutes

Summary of Resolutions

  1. ok to remove labels that were only inherited from UCs
  2. the relevant dcat terms will be used as tags in the GitHub issue tracker
Minutes formatted by Bert Bos's scribe.perl version 2.37 (2017/11/06 19:13:35), a reimplementation of David Booth's scribe.perl. See CVS log.


Succeeded: s/ad/add/

Succeeded: s/their own tags only/their tags too, and so we should harmonise at some point/

Succeeded: s/AndreaPerego, //

Succeeded: s/Idenfication/Identification

Succeeded: s/properties/terms

Succeeded: s/or inverse properties/

Succeeded: s/sub-classing/sub-classing and inverse properties