– DRAFT –
DXWG DCAT subgroup teleconference 27 March 2019 21:00 UTC

agenda

https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Meetings:DCAT-Telecon2019.03.27

+1

<AndreaPerego> +1

<alejandra> +1

<PWinstanley> +1

<riccardoAlbertoni> +1

<Makx> +1

approve minutes of last meeting

https://‌www.w3.org/‌2019/‌03/‌20-dxwgdcat-minutes

<PWinstanley> +1

<AndreaPerego> +1

<Makx> +1

+1

<riccardoAlbertoni> +1

<DaveBrowning> +1

<alejandra> +0 (was absent)

Resolved: approve minutes of last meeting

timing of future meetings

<PWinstanley> 20:00 UTC suits me

<AndreaPerego> +1 to shifting 1h

<alejandra> +1 to 20:00 UTC

invitation sent for 20:00 UTC on Wednesdays starting 2019-04-03

<Makx> +1

<DaveBrowning> +1

+1

<AndreaPerego> +1

<riccardoAlbertoni> +1

General release points

verify that we agree with announced release points

<PWinstanley> there is a 1.1 of DCAT-AP and there might be confusion with that

DaveBrowning: what is the release number? charter says 1.1, else 2.0?

<alejandra> https://‌www.w3.org/‌TR/‌vocab-dcat-2/

<PWinstanley> SimonCox: the version number is only what is in the header of the recommendation - it is just a designation

<alejandra> the URL already says 2

<PWinstanley> ... so my sense is that we shouldn't be shy. it is not just a few corrections. it is a significant change, so why not go to 2

<PWinstanley> +1 to SimonCox

<riccardoAlbertoni> +1 to SimonCox and alejandra

<Makx> +1

alejandra: match the version number with the URI

DaveBrowning: we need to communicate this to Phillipe

<alejandra> there are significant changes so it merits version 2.0

PWinstanley: should not confuse with minor tweaking e.g. DCAT-AP 1.1

AndreaPerego: 1.1 would not reflect the substantial changes; the thing that needs to be clarified to readers is that even though it is v2 it is backward compatible with v1
… in the text
… but what about the evergreen-standards ideas? 1.1 makes it easier to move to 1.2?

PWinstanley: evergreen standards is high priority for W3C; expected to deal with the backlog soon

<Zakim> SimonCox, you wanted to point out that v3 would be the next version!

PWinstanley: would that be another major version shift?

<PWinstanley> SimonCox: I think all this numbering gets tangled up

<PWinstanley> ... practices are different in different products

<PWinstanley> ... getting up to version 30 isn't as scary as it once was

<PWinstanley> ... so just restricting to cardinal numbers is ok

we shouldn't be scared about incrementing version numbers

alejandra: designation of future version is a discussion for the future

Makx: how about DCAT 2019?
… Firefox is now version 65 now, and no-one worries much, lets just use integers

<alejandra> to me the decision is taken considering if the changes are major or not

<PWinstanley> let's make a resolution

DaveBrowning: we agree that this is version 2, worry about the future later

<DaveBrowning> proposed: This version of the rec will be version 2.0, subsequent versioning tbd

<Makx> +1 to drop .0

<DaveBrowning> proposed: This version of the rec will be version 2, subsequent versioning tbd

<PWinstanley> +1

<alejandra> +1

<riccardoAlbertoni> +1

<Makx> +1

amendment = drop the .0

<AndreaPerego> 0

<DaveBrowning> +1

+1

Resolved: This version of the rec will be version 2, subsequent versioning tbd

DaveBrowning: Should all notes persist in CR?

DaveBrowning: ednotes will be dropped from the CR; should all others remain?
… in particular do we leave the NOTES that point out new features in the text?

alejandra: leave them in; important for people upgrading

<Makx> +1 to alejandra

<PWinstanley> +1 to alejandra - we can use styling to put them into a reduced size font or a box or similar

AndreaPerego: +1 to alejandra; need sanity check if some notes are really editor's notes

+1 to Peter - style new-feature notes different?

DaveBrowning: Code samples? where should they persist? Frozen GitHub branch used for FPWD. Same mechanism for CR?

+1

AndreaPerego: is there an issue related to generation of static HTML in pub process?

<DaveBrowning> https://‌www.w3.org/‌TR/‌vocab-dcat-2/#data-service-examples

DaveBrowning: this example shows link to 'DXWG code repository' which is live link to GitHub branch
… was not sure about it, but seemed to work well, and is consistent with mention of GitHub issue

AndreaPerego: is there a W3C requirement around this?

DaveBrowning: lets us assert this is how we want to do it, and wait for W3C to complain.

evergreen delivery would be assisted by retaining the same repository

DaveBrowning: alignment sections?
… 16, ApA, ApB

<DaveBrowning> https://‌w3c.github.io/‌dxwg/‌dcat/#other-w3c-recommendations

<riccardoAlbertoni> +1 to simonCox

<alejandra> +1, we did agree on dropping Annex B

<Makx> +1 to drop annex B

<PWinstanley> SimonCox: I think we agreed in a previous call that we would be dropping the alignment with other vocabularies (annexes A and B). there are partial alignments in other places

<riccardoAlbertoni> +1 to delete annex B and have the issues in the backlog

<PWinstanley> ... I think Annex B is straightforward. There certainly is a potential for joining 16 with A

<AndreaPerego> +1 to drop Annex B

<PWinstanley> ... I did some work, not very substantial. There was discussion about entailment and qualified relations

<PWinstanley> DaveBrowning: it is there for people with an interest

<PWinstanley> SimonCox: it is not said explicitly - but there is a consistent story, if not a good one. We can then drop A.2 if we add a little narrative here

<AndreaPerego> +1 to drop Annex A.2

<Makx> +1 to drop annex A2

suggest adding a mention in 9.1 noting that use of prov:qualifiedAttribution entails that dcat:Dataset is a subclass of prov:Entity (the afficionados woudl have spotted that already)

... otherwise we can drop A.2

<Makx> +1 to drop section 16

<AndreaPerego> +1 to drop Section 16

<alejandra> +1 to raising an issue

<alejandra> so that we can have discussion there

DaveBrowning: section 16 needs inspection, and discussion in an issue

AndreaPerego: was from an external contributor, we don't have time to check it, so maybe drop it

DaveBrowning: formal issue will allow us to engage with it and resolve it transparently
… specific problem is that it proposes new RDF properties in dcat: namespace

<DaveBrowning> proposed: raise issue to determine status of sect 16

DaveBrowning: e.g. dcat:records, dcat:datasets, dcat:services

<AndreaPerego> +1

+1

<DaveBrowning> +1

<PWinstanley> +1

<riccardoAlbertoni> +1

<Makx> +1

Resolved: raise issue to determine status of sect 16

also raise issue to remove annex B

<DaveBrowning> https://‌github.com/‌w3c/‌dxwg/‌issues/‌838

DaveBrowning: props to riccardoAlbertoni for sterling work on backlog

riccardoAlbertoni: we are accumulating a backlog, so need to make this transparent and orderly by putting explicit link to them

<riccardoAlbertoni> https://‌github.com/‌w3c/‌dxwg/‌issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Adcat+no%3Amilestone%09

riccardoAlbertoni: but many issues label:dcat are not in the backlog, or should we close a lot with 'won't fix'

<alejandra> +1

DaveBrowning: need a clear story about which are in backlog, and which are not

alejandra: 'backlog' milestone is a hack ...
… from when we stopped such frequent releases, when an existing milestone was renamed
… it is actually easy - any unresolved issue is automatically in the backlog!

<PWinstanley> +1 to prioritising for next version (we need to log our thinking somewhere)

AndreaPerego: but still need to prioritize the next ones that we will deal with
… will help people understand how the WG sees next priorities

riccardoAlbertoni: backlog milestone is useful - it allows us to show where discussion has been happening

<DaveBrowning> acl alejandra

alejandra: to AndreaPerego there is a prioritization, 3rd and 4th WD milestones; 4th WD was then renamed 'backlog'
… but what we are really talking about is a 'roadmap' which would be useful to get external feedback
… now we need to focus on issues at hand!

AndreaPerego: what is purpose of backlog? to inform readers about what will be addressed in the next release
… there are 42 issues not in the backlog milestone - too many to give direction to readers

<alejandra> I would change the name 'backlog'

<alejandra> maybe for 'roadmap'

or 'priority'

<PWinstanley> 'next steps'

<alejandra> yes, 'priority' is good

<riccardoAlbertoni> +1 to change the name of backlog

(a roadmap is a more discursive plan?)

Resolved: keep a milestone for 'priority' issues

<PWinstanley> I think it is important not to lose discussions

<PWinstanley> what we avoided is important to know

<riccardoAlbertoni> +1 to merge I agree with SimonCox

<riccardoAlbertoni> thanks a lot , bye

<Makx> bye now

it is important to do the merge so that classes that we know will go away no longer are visible in the ED