Meeting minutes
<DaveBrowning> s /https://
proposed: accept https://
<riccardoAlabertoni> PROPOSED: approve last meeting minutes https://
0
<riccardoAlabertoni> +1
<DaveBrowning> 1
<DaveBrowning> +1
RESOLUTION: accept https://
<riccardoAlabertoni> ttps://
<riccardoAlabertoni> h/www.w3.org/2017/dxwg/wiki/Meetings:Telecon2021.12.14/agenda: https://
publication and changes
<riccardoAlabertoni> https://
riccardoAlabertoni: I made changes in the past few hours and the PR is trying to update the references to DCAT2 inherited, and to try and convey that the discussion is now about version 2
… Previously the terms were prefaced with some indication that they were added in DCAT2. We are doing the same with DCAT3 - people jump through the document looking for specifics, and this note approach helps highlight changes at field level
DaveBrowning: I have investigated and think that what we did in DCAT 2 (indicating the new) brings attention to the new and also gives the rationale. I think that the rationale is something we should preserve, but perhaps it is also worthwhile showing the lifecycle of an entity. So, we would show what is new, but also indicate which version the entity was introduced / deprecated in
… Having design notes as part of the formal structure at the element level is useful
riccardoAlabertoni: we could embed some skos in the table / RDF
DaveBrowning: what is less clear in my mind is exactly how to execute this retention of design decisions, but that is something we can look at later
riccardoAlabertoni: Can we mark the PR as ready for review? The last comment in the PR is stacked on another relating to DataSeries. We are looking for feedback and people with a focus on this Class need to be aware that there is already some discussion on this topic
<riccardoAlabertoni> https://
how prescriptive do we want to be in components of a data series
riccardoAlabertoni: we could have a 3-level approach to the expected pattern for data series.
… When recommending DCAT2 we didn't deprecate DCAT1, but just added to it. The new implementation needs to consider that catalogs compliant with older versions of the standard might not be compatible with DCAT3 because the creation of a new class is going to be different to the handling of dataset series with the DCAT2 components
… Existing catalogs might decide not to update to the new version
… investment might be required to update to DCAT3
DaveBrowning: in the last meeting, we had to consider that DCAT3 might exclude from following a chunk of the user community because they might not want / be able to invest to upgrade
riccardoAlabertoni: Every state has a slightly different solution - the problem can be addressed in a bilateral way, but the actual requirement is to provide a general solution
PWinstanley: We need to consider / explore "SemOps" - automation for people to upgrade
… for example - https://
… this is probably an ideal candidate for connegp
riccardoAlabertoni: I am not sure about the exact approaches - I recall some countries using SQL to show dataset series.
… We can try to support a general model and the publishers can provide some transformation if they feel minded to do
… We need to avoid leaving out important use cases. We also need to broadcast the big picture widely so that people are familiar with it
DaveBrowning: The plenary needs to consider that they are comfortable with the direction of travel of the DCAT group
riccardoAlabertoni: move to adjourn.
… next meeting - 2022-01-11