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
<alejandra> +1 (after adding Simon regret's)
<SimonCox> add regrets from SImon to last week's minutes ...
<Makx> 0 (wasn't there)
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
Resolved: ok to remove labels that were only inherited from UCs
<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
SimonCox: In the previous meeting Arminhaller, PWinstanley, and RiccardoAlbertoni_ agreed to each look at a number of issues and review them.
<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
<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
<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.
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
<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
Succeeded: s/their own tags only/their tags too, and so we should harmonise at some point/
Succeeded: s/AndreaPerego, //
Succeeded: s/or inverse properties/
Succeeded: s/sub-classing/sub-classing and inverse properties