– DRAFT –
DXWG DCAT subgroup telecon

<alejandra> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Meetings:DCAT-Telecon2019.02.20#Main_agenda

confirm agenda

confirm minutes of previous meetings

<alejandra> https://‌www.w3.org/‌2019/‌02/‌05-dxwgdcat-minutes

https://‌www.w3.org/‌2019/‌02/‌05-dxwgdcat-minutes

<Makx> +1

<alejandra> +1

+1

<riccardoAlbertoni> +1

<PWinstanley> +1

<AndreaPerego> +1

Resolved: 2019-02-05 approved

https://‌www.w3.org/‌2019/‌02/‌06-dxwgdcat-minutes

<AndreaPerego> +1

<Makx> 0

<alejandra> +1

+1

<PWinstanley> +1

<riccardoAlbertoni> +1

Resolved: 2019-02-06 approved

https://‌www.w3.org/‌2019/‌02/‌13-dxwgdcat-minutes

+1

<alejandra> +1

<AndreaPerego> 0 (was not there)

<riccardoAlbertoni> +1

<Makx> +1

<PWinstanley> +1

Resolved: 2019-02-13 approved

Publication schedule

Makx email comment on deadlines

Sprints are not aligned with work packages for the identified WDs

... propose that next WD is the last before CR

... though team has decided to focus on sprints and the ED, rather than new formal WD

... propose one final WD mid-March

... going to CR mid-April

<AndreaPerego> Makx's mail: https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-wg/‌2019Feb/‌0358.html

alejandra: sprints were explicitly separate from milestones; rather focussed on groups of issues or themes that were important and not being given enough time
… team already decided to focus on content.

<PWinstanley> SimonCox: I think we decided to also, in lieu of more WD, send significant changes to the editors draft to the list

<PWinstanley> +1 to riccardoAlbertoni

<PWinstanley> afaik it is before

<AndreaPerego> Yes.

riccardoAlbertoni: do we need to collect implementation evidence before CR?

PWinstanley: yes

riccardoAlbertoni: implementation evidence is now a priority then

<riccardoAlbertoni> mid march final version

<AndreaPerego> Never done myself, but better start soon.

alejandra: if CR is mid-April, we need a final WD mid-March so we can spend that month working on implementation evidence

AndreaPerego: must start on implementation evidence now

<PWinstanley> here is the milestones calculator: https://‌w3c.github.io/‌spec-releases/‌milestones/

<PWinstanley> For example, to publish the Recommendation on June 27, the latest day to publish the Candidate Recommendation would be April 11: https://‌w3c.github.io/‌spec-releases/‌milestones/?rec=2019-06-27

AndreaPerego: 160 class/property combos - unlikely that we can provide evidence for all of these
… classes and properties for which we have no evidence might need to be marked 'non-normative'
… but particularly need to provide evidence for the added terms
… in some cases we might have to appeal to 'indirect evidence' - particularly around the services structures
… GeoDCAT-AP provides evidence for the requirement

<alejandra> DWBP implementation report: http://‌w3c.github.io/‌dwbp/‌dwbp-implementation-report.html

<riccardoAlbertoni> +1 to collect implementations in order to discover gaps in implementation, and decide if we can provide evidence on our own or drop from the normative part.

AndreaPerego: DWBP did include some 'forward looking' evidence in a way that was convincing enough to progress to Rec
… we should adopt similar approach
… all are requested to add material to AndreaPerego spreadsheet

<PWinstanley> SimonCox: I'm not convinced that covering all combos is required

<PWinstanley> ... we didn't do that in the spatial data on the web wg

<PWinstanley> ... Evidence of all combinations is a big challenge, esp where inheritance is involved

<AndreaPerego> DCAT 2014 implementation report: https://‌www.w3.org/‌2011/‌gld/‌wiki/‌DCAT_Implementations#Summary_of_terms_usage

<Zakim> alejandra, you wanted to ask about evidence for 'abstract' classes and to mention about user surveys that PROV did

AndreaPerego: consult with Dave Raggett

alejandra: need to be sensible about evidence of 'abstract' classes
… shoudl we send out a survey?

AndreaPerego: not enough time for a real survey
… need evidence of 2 implementation for each normative elements
… we are already in pretty good shape for much of it

riccardoAlbertoni: some of the implementations can be from group members

alejandra: can riccardoAlbertoni provide some implementations?

<AndreaPerego> The spreadsheet for collecting implementation evidence is here: https://‌docs.google.com/‌spreadsheets/‌d/‌1eEVUuPFAGO2GjS5ocxylY8T1AlpqlwnOTc3er_Mhcv4/‌edit?usp=sharing

riccardoAlbertoni: catalog of thesauri, might be able to upgrade this to fill gaps

AndreaPerego: asks riccardoAlbertoni to look at the list and see the gaps
… of course these are more glaring for the new elements
… risk of misunderstanding of inheritance e.g. Catalog inherits dct:temporal, but few catalogs describe themselves this way
… inheritance of a set of (optional) properties from an abstract class is a useful feature, but implications must be clear

<PWinstanley> I will get in touch with dsr

Action: PWinstanley to contact DSR to verify timeline, and what artefacts are required at each stage

<trackbot> Sorry, but no Tracker is associated with this channel.

AndreaPerego: we should invite DSR to DCAT call?

PWinstanley: better to get it in writing (first)

<AndreaPerego> +1

riccardoAlbertoni: also need to ask DSR about references to 3rd Party vocabs in normative parts
… esp. in relation to dependencies on non-normative specs or non-normative parts of normative specs
… e.g. DQV, parts of ADMS

AndreaPerego: the key criterion is stability and an orderly governance process, so they won't disappear unexpectedly
… also cannot be changed arbitrarily. There is lots of normative use of non-normative/informal dependencies.
… this should be done sensibly.

<PWinstanley> SimonCox: I raised the matter of references to non-normative things - respec has some rules, and I was tripping over ones relating to the organisation of the bibliography

alejandra: do we need another sprint? e.g. implementation report

<AndreaPerego> +1 from me

+1 to a sprint for the implementation report

outstanding actions

<alejandra> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌open

<AndreaPerego> Mine are yet to be done - sorry.

Annette's services proposal - she was requested to provide some worked examples

public comments list

AndreaPerego: to draft response to Luca

closing issues

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22due+for+closing%22+label%3A%22dcat%22

<AndreaPerego> I think it can be closed.

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌pull/‌759

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

<trackbot> Sorry, but no Tracker is associated with this channel.

<alejandra> proposed: close issue https://‌github.com/‌w3c/‌dxwg/‌issues/‌675

<AndreaPerego> +1

+1

<riccardoAlbertoni> +1

<alejandra> +1

Resolved: close #675

<alejandra> discussed issue https://‌github.com/‌w3c/‌dxwg/‌issues/‌530

<alejandra> can be closed

<alejandra> as we replied to Clemens

<alejandra> PR: https://‌github.com/‌w3c/‌dxwg/‌pull/‌746

alejandra: next point is PR with Makx proposal about packaging & compression. 5 voted for proposal 2

<alejandra> voting in the issue: https://‌github.com/‌w3c/‌dxwg/‌pull/‌746#issuecomment-462699155

Makx: I created 2 properties with definitions and links, I put a line in the change log and included a couple of lines in the Turtle file.

alejandra: I noticed SimonCox had made a change request on the Turtle file, so maybe you did it in a different branch. I added the changes to the turtle file and the change log.

Makx: I made the changes in my branch and pushed upstream, my file has the changes

<alejandra> Makx's latest changes are in a different branch: https://‌github.com/‌w3c/‌dxwg/‌commit/‌6e5950888905fa4cce456bce4c767ac7f3ddc061

<alejandra> two branches: dcat-makx-packaging

alejandra: I will investigate and see how we can merge your change

<alejandra> and makxdekkers-patch-1

Makx: I made one branch and SimonCox made another

alejandra: I will look at this and sort out

Makx: the definitions in dcat-makx-packaging are what I did today

<alejandra> proposed: agree on Makx's proposal of adding two properties: dcat:compressFormat and dcat:packageFormat

<riccardoAlbertoni> +1

<alejandra> +1

+1

<AndreaPerego> 0

<Makx> +1

AndreaPerego: I have no strong opinion on this
… the media type determines if it is compressed or packaged
… the only thought I have is that looking at how people will have to use these properties introduces decisions that they might not be able to make.
… and software is able to behave correctly based on mediatype
… this is therefore treated transparently by software agents
… additional properties might make this more complicated for people

alejandra: is a super-prop required? people might just use that

Makx: my initial proposal was for one, but I created two and the vote went for that

alejandra: we need to look at examples; if it is too complex then we can determine if we roll back this decision

<AndreaPerego> +1

+1

<riccardoAlbertoni> +1 to go ahead

Resolved: agree on Makx's proposal of adding two properties: dcat:compressFormat and dcat:packageFormat

<AndreaPerego> Thanks, bye bye!

alejandra: we might organise another sprint, but otherwise, same time next week

<alejandra> thanks Simon and Peter for scribing!