– DRAFT –
DXWG Weekly Telco
17 April 2018
PWinstanley: minutes of last meeting
<PWinstanley> https://www.w3.org/2018/04/03-dxwg-minutes
<LarsG> +0 (wasn't there)
<PWinstanley> 0
<riccardoAlbertoni> +1
Resolved: approved minutes of April 3
<annette_g> wasn't there
PWinstanley: will create a table so that people can say if they are going
kcoyle has given thurs and fri of that week, but we can change
PWinstanley: Riccardo has offered to arrange food 60 euros (breaks, lunch)
… this gives us possibility for long time with folks coming in from Australia by phone
… let us know if you opt out
<PWinstanley> https://www.w3.org/2017/dxwg/wiki/F2f3
PWinstanley: https://www.w3.org/2017/dxwg/wiki/F2f3 has planner for in person and remote participation
… has section for a dump of topics so we don't forget any
<riccardoAlbertoni> https://www.w3.org/2017/dxwg/wiki/F2f3#Coffe_breaks_and_Lunches
riccardoAlbertoni: about the food - table on planning page - please fill in any requirements
https://www.w3.org/2017/dxwg/track/actions/open
PWinstanley: # 83 - dsr doesn't know how, will ask
… # 94 is still open
PWinstanley: asking Makx about 105
roba: #88 - unknown?
<Makx> talking about https://www.w3.org/2017/dxwg/track/actions/84?
LarsG: didn't have much of a last meeting; couldn't get webex to work
<Makx> I did #105
LarsG: keep 88
<Makx> Can reiterate propsals for #84
kcoyle: close 97, 99
close 101; by Ixchel
<Makx> close #105 please
<Makx> #105 https://github.com/w3c/dxwg/tree/dcat-topic104-makx
PWinstanley: #96 (Jaro) can be closed
PWinstanley: #105 done by Makx
… #84 still open (Makx) - similar to #85 (andrea)
PWinstanley: issues need to be clarified
SimonCox: been away for a week; has looked at editorial questions; sent mail to chairs list
… some small issues of broken links (syntax checker); but two issues still hanging
… due to respec template, won't accept same ID in multiple places in document
… asking DaveR how to resolve this
… some of the broken links are incomplete but will be; also a legacy link that goes to some older UK documents
… has pinged owners of the links, and they will fix those
… some small syntax issues; thinks to have answered all of dsr's questions
… but still a pull request regarding including services in FPWD; so far no objections; waiting for an editor to accept this pull request
<AndreaPerego> To sort this out, it may be worth having a resolution now.
dsr: there's a link checker and css checker; as per multple IDs - can be fixed by hand, albeit a pain to do
SimonCox: I used respec syntax to drop in links in multiple places in the document because referred to in multiple places
… this is causing multiple IDs in the document
… this makes sense from the meaning of the document, but respec rejects
dsr: script might be fixed, but for now it may be easier to make document changes
SimonCox: issue of whether new dcat will actually replace old; so identity of the document depends on a decision
… in the meanwhile, as soon as we push fpwd, this replaces original 2014
dsr: dated URL still points to original dcat
<Makx> I think we can't replace a recommendation by a working draft
dsr: latest version doesn't have a date; would point to fpwd
<Makx> draft should live in differnt place, final recommendation might replace old one
<AndreaPerego> Just to note that the option is to have (or not) a separate URI for the spec. The DCAT namespace URI won't change (http://www.w3.org/ns/dcat#).
PWinstanley: as makx points out, shouldn't overlay a rec with a fpwd; this is a w3c decision
… unless you know to drill down you won't see the current document
dsr: people need to read the text at the beginning of the document
PWinstanley: how can we make it more obvious?
dsr: main question is whether this updates DCAT or provides a new rec
<Makx> People don't read introductions
phila: makx is right (people don't read), dsr is right. question is: what is the long term aim?
<Makx> Long term I'd say new rec overwrites old rec
phila: two things 1) in the links at the top you can add in "current rec" link
<Makx> But drafts do not overwrite old rec
<annette_g> I agree with Makx
phila: 2) or create a temporary short URL
<Makx> I vote fdor both 1 and 2
phila: sometimes short URL is changed - e.g. dcat1.1 could later point to dcat
<AndreaPerego> Temporary short URL looks safer - we have time to decide whether we are going or not to replate previous REC.
annette_g: feel strong that the current rec should be the one at the default url; what we are doing should eventually take that place
<Makx> +1 to simon
annette_g: meanwhile have dcat 2014 point to working draft
<Makx> annette_g +1
roba: 3 things: original version; revised version; current version - these all need URLs
<Zakim> SimonCox, you wanted to note that short name would be /dcat-rev not /dcat-1-1
roba: give this a fpwd a unique uri
SimonCox: dave already pointed out that there are separate ids for this; what is unfriendly is that there are the two dated versions
… what we are arguing about whether "current" should point to original or revised
<annette_g> I want https://www.w3.org/TR/vocab-dcat/ to point to a full recommendation always.
<antoine> annette_g++
<AndreaPerego> Should be /dcat-rev -> /vocab-dcat-rev
<Makx> +1 annette_g
SimonCox: #2 we are not going to call the new version DCAT 1.1; we decided this already
… we're calling original 2014; revision DCAT revision
PWinstanley: can we have current always be a final version?
<phila> apologies, I had forgotten, but had known, that it'll be called dcat-rev
dsr: the latest should get the "plain" url
<Makx> I'd say the drafts live under /vocab-dcat-rev. When agreed as new rec, then goes under /vocab-dcat/
SimonCox: what we're uncovering is an issue in w3c policy around priorities of documents; seems to say
<Makx> with link to previous version
SimonCox: that undated points to the most recent
… our sense is that the undated should point to the one with the higher status
<Makx> +1
<antoine> +1
annette_g: "revision" - is that a numbered revision or just a revision?
<Makx> Revisions also have dated URLs
dsr: if we are creating a new standard then having version in the name would be a mistake
SimonCox: We concluded that at this point we do not know if it will be a distinct thing; depends on backward compatibility
<Makx> Undated /vocab-dcat-rev/ should point to latest draft
SimonCox: if compatible, then no version designator is needed; so we have finessed this by removing the version # in the document
PWinstanley: as per makx, dcat-rev would point to latest draft
annette_g: seems wiser to assume that a number would be helpful, not "rev-rev"
<Makx> No numbers please!
SimonCox: reiterates uncertainty about compatibility at this point in the process
antoine: still puzzled about original requirement in discussion; for now, why not used a numbered or dated version?
… we don't want our in progress work replacing the stable one
<Makx> Dated versions are OK in any case, the question is do we really need a short URL?
<SimonCox> Sorry for jumping across the queue. I didn't want the discussion to overlook the earlier resolutions.
<annette_g> why not admit that we are revising? Old uses can still point to the original URI.
SimonCox: versioning very difficult in RDF practice; if you use version then you don't know you have the same term
… not clear what has and what has not changed
<Makx> I liked the eqrlier proposal: vocab-dcat always links the the current rec; vocab-dcat-rev always links to the latest draft. everything else can be done with dated URL, pointing backwards
SimonCox: do not change uri when there is no change in the intention
<annette_g> Sorry, but I don't think what we are making is the same thing, by intention.
<Makx> -1 annette_g
SimonCox: also applies to documentation; challenge is that we do not know what the compatibility will be
<Makx> Let's look at DCMI for guidance
kcoyle: others have done this, so we should consider that we have a choice, even if more work
antoine: all production usage is the current rec; therefore this version will never be used
PWinstanley: vocab-dcat is current, vocab-dcat-rev for the in-progress
<riccardoAlbertoni> +1 to peter
<SimonCox> +1
<AndreaPerego> +1
<annette_g> +1
<Makx> +1
PROPOSED: vocab-dcat is current, vocab-dcat-rev for the in-progress
<DaveBrowning> +1
<Makx> suggest current=current rec
<AndreaPerego> +1
<antoine> +1 even if I don't see the need for a permanent alias (-rev) for refering to the working versions
Proposed: vocab-dcat is current, vocab-dcat-rev for the in-progress, and they are dated and point to the undated uris
<Makx> -1
<Makx> needs to say current rec!
<PWinstanley> Makx can you explain please?
<antoine> Makx just makes a comment on the wording of the first part
<riccardoAlbertoni> s\current,\current rec,
<annette_g> "Proposed: vocab-dcat is current rec"
<Makx> if we say current, someone could thing 'current draft'
<SimonCox> dsr: I will need some assistance with config.js
<AndreaPerego> Proposed: vocab-dcat is current rec, vocab-dcat-rev for the in-progress, and they are dated and point to the undated uris
<Makx> ok with change by riccardo
<Makx> also add a noun after 'in-progress'
PROPOSED: vocab-dcat is current rec, vocab-dcat-rev for the in-progress work, and they are dated and point to the undated uris
<Makx> perfect!
<AndreaPerego> +1
<riccardoAlbertoni> +1
<annette_g> +1
<Makx> +1
+1
<SimonCox> +1
<PWinstanley> +1
<phila> +1
<LarsG> +1
<antoine> +1
<roba> +1
<DaveBrowning> +1
Resolved: vocab-dcat is current rec, vocab-dcat-rev for the in-progress work, and they are dated and point to the undated uris
<Ixchel> +1
<Zakim> AndreaPerego, you wanted to ask if we can have a resolution for https://github.com/w3c/dxwg/pull/183
<Makx> sorry 'undated uris' or 'dated uris'?
<Makx> I think 'dated uris'
dated uris point to the undated, no?
<SimonCox> Proposed: merge https://github.com/w3c/dxwg/pull/183
<Makx> no i think it is the other way around
<SimonCox> +1
+1
<DaveBrowning> +1
<roba> +1
<AndreaPerego> +1
<PWinstanley> +1
<annette_g> +1
<Makx> ok sorry for confusing things
Resolved: merge https://github.com/w3c/dxwg/pull/183
PWinstanley: what is the workflow for pull requests?
LarsG: haven't thought about that
PWinstanley: who in the group is reviewing and merging PRs?
LarsG: Any editors can merge (only 3 in the group, all 3 are editors)
<antoine> https://github.com/w3c/dxwg/pull/198
<SimonCox> See https://www.w3.org/2017/dxwg/wiki/GitHub_etiquette
antoine: points to pull request from this morning; didn't know who would approve; now clearer
SimonCox: we tried to write the rules for this (see last link); only designated editors are merging
… but do not merge their own proposals
roba: work that nick and I are doing is closer to dcat group than negotiation group
… may need its own activity eventually; now working on a separate branch and pull request will go to dcat editors
<antoine> actually I think my confusion comes from the fact that there's no general group on profiles. I thought PR 198 was not about negotiation per se.
<SimonCox> I have to leave to another meeting
<riccardoAlbertoni> bye ! goodnight/ goodday!
<LarsG> Good night everyone
<annette_g> bye!
<PWinstanley> bye
<Makx> bye
<PWinstanley> thanks Phil & Andrea.
<PWinstanley> Bye all