W3C

– DRAFT –
DXWG DCAT subgroup teleconference

17 January 2018

Meeting Minutes

hello all - who is supposed to start the webex meeting?

never mind, I am joining...

<SimonCox> See resources listed here https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌DCAT_Vocabulary_team_working_space

<SimonCox> See draft https://‌w3c.github.io/‌dxwg/‌dcat/

stijngoedertier_AIV: from the Flemish Information entity

stijngoedertier_AIV: also attended some of the plenary meetings

SimonCox: volunteered to coordinate this group, mainly focusing on process and not content
… in support of that, I've pulled together the beginnings of a wiki page with a list of resources
https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌DCAT_Vocabulary_team_working_space
… original DCAT 1.0 recommendation
… alejandra and myself copied across that material into a new respec document
… available at: https://‌w3c.github.io/‌dxwg/‌dcat/
… so far, there have been no changes to version 1.0
… only content that has changed relative to version 1 is the paragraph on 'motivation for change'
… and addition of a few more rdf prefixes
… the rest has been copied verbatim across as indicated in the notes
… our goal is to make modifications on the DCAT vocabulary triggered by the UCRs
… link to the UCR document: https://‌www.w3.org/‌TR/‌dcat-ucr/#Tags
… DCAT RDF

at https://‌github.com/‌w3c/‌dxwg/‌tree/‌gh-pages/‌dcat/‌rdf

... Nick present in webex

... recently rejoined CSIRO

... when we discussed in plenary, 4 people put their hands up to be editors of the document

... that's Peter W, Dave B, Alejandra and myself

... this is the kick-off meeting for this activity

... and gives us a chance to decide the mode of operation

... deliverable due on Spring 2018 (northen hemisphere)

... fairly tight deadline to work on the draft

... by no means, it should not be a final product (due on other 18 months) but trigger responses from the community

... allow the broader community to provide feedback

... as the documents are open and there will be a call for comments

... main thing that is supposed to trigger the changes/modifications/updates to the document are the requirements

... that have been extracted from the use cases

... if you've followed the correspondence and the meetings, you'll know that we've decided to follow github

... and its use its issue tracker

... I've proposed to include the requirements in the tracker

<SimonCox> UCR Requirements https://‌www.w3.org/‌TR/‌dcat-ucr/#Requirements

https://‌github.com/‌w3c/‌dxwg/‌issues

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

SimonCox: requirement 1 added manually: https://‌github.com/‌w3c/‌dxwg/‌issues/‌50
… they can be tagged (in this case inherited from the use case)
… having the requirements as issues, we can keep track and do our work
… open the floor for comments about this process
… and what are your expectations

<SimonCox> ack: arminhaller

arminhaller: question to clarify - do you plan to use github and not the w3c issue tracker

SimonCox: yes, that's the proposal

<SimonCox> alejandra: agrees with use of GitHub for issues

<SimonCox> ... will allow mods to be tied to issues formally

<SimonCox> ... Jaroslav is investigating automation of moving reqs to github issues

<SimonCox> ... by end of week

<SimonCox> ... has additional issues to add

<SimonCox> ... also existing extensions to DCAT which mostly triggered UCs

SimonCox: ok about the additions
… let's reserve the tag 'requirement' for those in the UCR
… under the process we have a duty to address all the requirements
… either to satisfy them or to indicate that we cannot satisfy them
… other issues can be introduced as long as we can track them

<SimonCox> alejandra: mods to document should be done through branching and PRs

this is the Github etiquette: https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌GitHub_etiquette

SimonCox: the document is the primary artefact that we'll be delivering
… everybody is welcome to make modifications to the document following the Github etiquette
… work on a branch
… you can push the branch to the dxwg github repository
… the only people that can merge proposals into the master are the editors
… so you should issue a Pull Request
… if the editors are making edits, they will follow the same process and other editor needs to merge the Pull Request
… this does require that you learn git/github to be able to deal with this process

<DaveBrowning> +1 for the process

<riccardoAlbertoni_> +1 to the described github etiquette described

<DaveBrowning> .. and the etiquette

<SimonCox> alejandra: editors will create extra issues from discussion on mailing list, when necessary

<SimonCox> ... also people external to project may work on forks

PROPOSED: agree on the process and github etiquette described above

+1

<SimonCox> +1

<PWinstanley> +1

<DaveBrowning> +1

<arminhaller> +1

<stijngoedertier_AIV> +1

<Makx> +1 but don't understand it yet

+1 from Nick on the phone

<SimonCox> also NickCar +1

<riccardoAlbertoni_> +1

Resolved: agreement on the process and github etiquette

SimonCox: in terms of getting some work done, we are a little bit held up as the requirements don't appear yet as github issues
… but they way you filter out the ones that apply to github is going to this link...

https://‌github.com/‌w3c/‌dxwg/‌issues?q=is%3Aissue+is%3Aopen+label%3Arequirement

<stijngoedertier_AIV> https://‌www.w3.org/‌TR/‌dcat-ucr/#Tags

https://‌www.w3.org/‌TR/‌dcat-ucr/#Requirements

SimonCox: we can filter out those requirements tagged with DCAT from here: https://‌www.w3.org/‌TR/‌dcat-ucr/#Tags
… we need to review and make sure that the tags are correct
… I suggest that we make that revision and ensure that the tagging is correct
… easiest way to modify them would be to have them as github issues
… but we can start preparing for that review

<SimonCox> regret: ANdreaPerego

SimonCox: many of us submitted use cases, but the extraction of requirements was largely done by the UCR editors
… they also sorted the requirements under subheading (from identification on...)
… profiling are less related to DCAT per se...
… adaptations or uses of DCAT vocabulary
… should we try a divide and conquer approach to review this?

<SimonCox> alejandra: split requirements, compile material, --> less work individually

<PWinstanley> 21:00 UTC +1

<riccardoAlbertoni_> yes I can

<SimonCox> ... Andrea has overlapping meeting - could we meet an hour later

<SimonCox> ?

<Makx> fine for me

<stijngoedertier_AIV> 21:00 UTC is ok

<arminhaller> +1 for 21:00 UTC

<SimonCox> +1 to move to 21:00

<DaveBrowning> +1

<SimonCox> However, note that clocks change again in April

<SimonCox> Makx: what are meetings for?

Makx: I would prefer to have the discussions in github tracker
… and use the meetings for getting consensus
… as also the late time is not too good for me

SimonCox: I agree - the meetings would be to get together and verify that the process is working
… to get people that committed on an action to report

Makx: status meetings

SimonCox: yes, exactly

<Makx> ok with me

SimonCox: the real record should be the record of changes in github issues (primary thread) and changes to the document tied to those issues will get us a proper record

SimonCox: I won't be available next week to run the meeting

PROPOSED: adjust timing of this meeting to 21:00 UTC (instead of the 20:00 UTC that we agreed now)

<SimonCox> +1

<arminhaller> +1

+1

<AndreaPerego> +100

<riccardoAlbertoni_> +1

<DaveBrowning> +1

<Makx> +1

<SimonCox> NickCar +1

<PWinstanley> +1

<stijngoedertier_AIV> +1

Resolved: we will propose back to plenary the change of time that we discussed in this call for 21:00 UTC

SimonCox: action on everyone, familiarize yourself with the list of requirements
… hopefully within the next few days we will have the requirements as github issues
… maybe we need to create labels for each of the subsections of the requirements

<PWinstanley> assume that it will be agreed

<riccardoAlbertoni_> +1 to send the mail

<PWinstanley> and make tentative plans

Action: send email to dxwg list announcing intention to shift timeing of DXWGDCAT group back one hour

Action: alejandra to create GitHub labels for subsections

<riccardoAlbertoni_> thanks, bye!

<Makx> thanks bye

<PWinstanley> thanks .. .bye

thanks, bye!

<SimonCox> Thanks Andrea

<AndreaPerego> A pleasure

Summary of Action Items

  1. send email to dxwg list announcing intention to shift timeing of DXWGDCAT group back one hour
  2. alejandra to create GitHub labels for subsections

Summary of Resolutions

  1. agreement on the process and github etiquette
  2. we will propose back to plenary the change of time that we discussed in this call for 21:00 UTC
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.

Diagnostics

Succeeded: s/requiremnets/requirements

Succeeded: s/... where are they recorded?//