Meeting minutes
Approval of last meeting's minutes (https://www.w3.org/2026/07/16-dxwg-minutes )
<RiccardoAlbertoni> Propose: accept last meeting minutes - https://
<RiccardoAlbertoni> +1
<annette_g> +1
<roba> +1
<nicholascar> +0
<Simon> +1
<LarsG> +1
<Dan> +1
<steveR> +1
<Arofan> +1
RESOLUTION: accept last meeting minutes - https://
Task forces and deliverables (continued from previous meeting): TF Profile
<steveR> https://
nicholascar: planning first draft of profiles and connegp document
nicholascar: will be able to work asynchronously using GitHub
nicholascar: expecting most of the editors to be participating
nicholascar: in telecons
roba: what are motivations for change? What are the important open issues?
nicholascar: SHACL WG has done narrower task, so needs to push up some issues to profiles doc
nicholascar: some profiles roles and vocabulary updates needed
nicholascar: 'profiling' as a concept needs clarification in profiles document , 1-2 paras
nicholascar: i.e., small changes pushed up from SHACL WG
ack: annette_g
annette_g: what about items that are tagged 'note'?
annette_g: if these move to REC then need a vote in this group?
roba: connegp is on REC track, promotion of profiles to RC track is mentioned in charter
<nicholascar> Charter: https://
<nicholascar> 3.3 Tentative Deliverables
annette_g: thinks that they are not classed as REC
nicholascar: we have interest and people to move to REC as foreseen in charter
roba: profiles roles vocabulary is a 'register' of terms - would be better published as dynamic register rather than static document or file
<Arofan> If we want to be strict according to the wording in the chater, having interst and participants will lead us to "consider" the following actions. Does this still require agreement in the group? (I suspect this will be pro forma...)
<annette_g> The charter says "Depending on the interest and availability of Working Group participants, the Working Group may also consider: " these items
antoine: the registry should be defined as part of the REC then it can be maintained dynamically
roba: are their precendent?
pchampin: not aware of any
<Arofan> I agree with Annette's reading here
annette_g: charter allow for the group to _choose_ to moving notes to REC, which still needs a vote
annette_g: requires a registry - many ways to do this, considering the need for an API then we need detail so this isn't a big mess with multiple implementations
annette_g: early in WG is best time to clarify these issues
roba: don't know of any registry precendents. Yes, would be helpful to formally agree to promote notes to REC
roba: the concerns could be separated in the document, allowing for multiple implementations of registry - should be discussed in the connegp workforce - don't conflate connegp and prof
<nicholascar> The Register Track: https://
RiccardoAlbertoni: more detail on registry options?
pchampin: registry is the way to make REC open ended
pchampin: registry defines what is information that must be submitted for registration of an item
pchampin: in case of extensible vocabulary this allows items to be added later
<roba> like the IANA link relations and media types registers
pchampin: does not need to be maintained by the WG, can be delegated to a third party
pchampin: new items in registry must not change conformance
<Arofan> Annette raised a point of process which was not yet addressed: do we need as a group to agree that the additional items in the carter will be carried forward? Does this require a vote? I am happy with Rob's answer's but the question still seems open to me.
simon: is annette_g asking for a proposal now?
annette_g: not now - wait until we have settled down the group so we can all consider the proposal
FranckC: could annette_g join TF for one meeting to clarify goals?
annette_g: need to make choices about concrete proposal so goals and choices are optimised
tools
Tools: GitHub repositories (see https://github.com/w3c/dxwg/issues/1641)
<FranckC> Simon: describes issue w3c/
<FranckC> Simon: the proposal is to create seperate GitHub repository for each deliverable
<FranckC> ... easy for new documents, harder for existing ones
RiccardoAlbertoni: seems that there is a general consensus to go this direction
RiccardoAlbertoni: DCAT has a long history in GitHub and with some associated Wikis, so will need some care
RiccardoAlbertoni: we can agree in this meeting, and then figure out who is responsible for technical work
FranckC: DCAT is the most complex case
should be easy for VVD and DQV
RiccardoAlbertoni: could DQV history be transferred from earlier repo dwbp?
pchampin: tools work better with one deliverable per repository
<RiccardoAlbertoni> w3c/
<roba> can we rename, then create a new on with the old name that brings it in as a submodule?
pchampin: current dx repo is dominated with DCAT - perhaps keep existing dxwg repo for DCAT
RiccardoAlbertoni: need to preserve links from published papers
<pchampin> the URLs of issues would still work if we rename the repo (GH would redirect to the new URL)
RiccardoAlbertoni: renaming github repo might break links?
pchampin: links redirect, gh-pages don't
Simon: for gh-pages, just need to leave a stub HTML with a redirect in the header
<roba> no objection - put to vote?
everyone please review w3c/
RiccardoAlbertoni: note that DCAT will require particular attention
FranckC: plan to vote on the proposal in next meeting
Tools: Wiki (https://www.w3.org/2017/dxwg/wiki/Main_Page )
FranckC: Wiki needs a lot of update. Clarify - we are talking about the W3C Wiki _not_ GitHub artefacts
FranckC: Antoine Isaac will propose how to reorganise Wiki
FranckC: can anyone interested please send Antoine suggestions
AOB
<pchampin> it's been a "short" meeting after all :)
bye
<FranckC> bye