DXWG Weekly Telco

17 April 2018

Meeting Minutes


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

f2f4 (Lyon, late october)

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

f2f3 Genoa, May 8-9

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

open items


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)

DCAT subgroup

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


<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


<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

Summary of Resolutions

  1. approved minutes of April 3
  2. vocab-dcat is current rec, vocab-dcat-rev for the in-progress work, and they are dated and point to the undated uris
  3. merge https://‌github.com/‌w3c/‌dxwg/‌pull/‌183
Minutes formatted by Bert Bos's scribe.perl version 2.41 (2018/03/23 13:13:49), a reimplementation of David Booth's scribe.perl. See CVS log.