DXWG DCAT subgroup teleconference 27 March 2019 21:00 UTC

27 March 2019

Meeting minutes




<AndreaPerego> +1

<alejandra> +1

<PWinstanley> +1

<riccardoAlbertoni> +1

<Makx> +1

approve minutes of last meeting


<PWinstanley> +1

<AndreaPerego> +1

<Makx> +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


<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


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?


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


<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

Summary of resolutions

  1. approve minutes of last meeting
  2. This version of the rec will be version 2, subsequent versioning tbd
  3. raise issue to determine status of sect 16
  4. keep a milestone for 'priority' issues
Minutes manually created (not a transcript), formatted by Bert Bos's scribe.perl version 2.49 (2018/09/19 15:29:32), a reimplementation of David Booth's scribe.perl. See CVS log.


Succeeded: s/Should all notes persist in CR?/DaveBrowning: Should all notes persist in CR?/

Succeeded: s/relaly/really/