<alejandra> https://www.w3.org/2017/dxwg/wiki/Meetings:DCAT-Telecon2019.02.20#Main_agenda
<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
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
<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
AndreaPerego: to draft response to Luca
<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!
Succeeded: s/implementation/implementations
Succeeded: s/stablility/stability
Succeeded: s/spring/sprint/
Succeeded: s/proposed /proposed: /