Meeting minutes
<riccardoAlbertoni> PROPOSED: approve last meeting minutes https://
<riccardoAlbertoni> +1
+1
<AndreaPerego> +1
<riccardoAlbertoni> +1
RESOLUTION: approve last meeting minutes https://
<riccardoAlbertoni> https://
<riccardoAlbertoni> ack
AndreaPerego: I see that Annette has raised some questions/issues via the mailing list
… on the DCAT WD
riccardoAlbertoni: Vote was generally positive, and procedure does allow for some disagreement on WD
… Chair can move it forward. But there has been silence on all channels
AndreaPerego: Understand the open issues so Annette is not wrong but we planned to use WD to get feedback
… usually we have approval from everyone.
riccardoAlbertoni: I have asked Peter what he intends....
DaveBrowning: The plenary had limited attendance and so discussion wasn't possible
Concerns on DCAT-AP
MakxDekkers: Currently looking at national profiles. Some implementers are against creating data sets for time series for geographical data
… Some previous practice used more of a 'bag' approach, and some have been using this for data series
… been a long lasting discussion (at least 2016)
… Recent discussion has now come through to issues in DXWG github, so we now have an open discussion
… Clearly divergent approaches - 'dropping files into data set 'bag of resources''
… We have discussed before - it depends on the workflow practices
… Some practitioners don't want to put effort into description etc
… This leads to duplication - might be easier for producer but not consumer will need to cope with both/either
… We now faced with (sub)group of implementers who want to persist their current workflow for publishing
… DCAT 3 provides what we think is better way but we need to have a coherant approach to the subgroup practice
AndreaPerego: Question - when we have these discussions, do they appreciate we aren't banning the existing practice, but providing the series approach
… based on other implementations
… Do the people resisting realise we aren't being prescriptive? That it may take time for people to move or adapt
MakxDekkers: We have the base DCAT approach where there is lattitude, but we have a network of implementers who need/want to be consistant
… Is the recommendation clear enough on this?
… I think the rec is very clear about how to do it if you 'come from outside'
… with no legacy
… For example if you have series at distribution then properties can end up being copied from Dataset (since they might change over time, for example)
<riccardoAlbertoni> https://
riccardoAlbertoni: I agree with the point/concerns
… but intent was to bias it towards 'series at dataset' but not prescriptive since we know there is existing practices
MakxDekkers: That seems not so desirable - if a standard has too many options it makes it more complicated
riccardoAlbertoni: Intention was not to be evenhanded but to bias to our way (supported by use cases), but agree current draft needs to be better explained/examples
AndreaPerego: My recollection is that the text was to reflect the current practice specifically
<riccardoAlbertoni> inSeries property note says "Normally, child datasets in dataset series are represented as dcat:Dataset. The use of dcat:Distribution for typing child datasets is however recognized as a possible alternative, whenever it addresses more effectively the requirements of a given application scenario."
AndreaPerego: Perhaps we have been overly cautious. Would like to say 'we have a solution - based on use cases'
… but people are doing things differently.
… as it stands their approach is conformant but conceptually its quite different
… We could make this more explicit
MakxDekkers: It says in section 12.3 that we expect people to change on way to DCAT 3.
… from a DCAT-AP implementation angle this risk of multiple approaches is quite worrying
… Could the spec be made more prescriptive ? Remove the 'not formally incompatible' comment?
MakxDekkers: Key question - does DXWG want to be more presciptive.....?
riccardoAlbertoni: One issue is whether we would have implementation evidence for the new approach in time for publication
AndreaPerego: These changes/extensions were motivated by provided use cases.. perhaps we can check, but we shouldn't rely just on that
riccardoAlbertoni: In SKOS they used 'feature at risk', so perhaps we could
… suggest a clear direction, but mark the feature as 'at risk' and if there is no evidence by approval time....?
AndreaPerego: I think there will be implementations. But also that they are different conceptually from some existing practice
… Question - do the implementers that have raised issues have any way forward
MakxDekkers: They aren't keen on the new features and would potentially not use them
… and not change their systems. Since we have potentially divergent paths here, we do need to be sure that DXWG is okay with that. We have a new solution - elegant even - but some existent practictioners
… may not be able to change
… People may keep doing what they are doing since they have tools, training etc
AndreaPerego: Would using more modularity provide an options (thinking aloud...)
MakxDekkers: Probably needs the plenary to discuss/agree the risks/outcomes of these newer features
AndreaPerego: And also might apply to versioning changes
… we have clear use cases for more sophisticated versioning, different from what people do now
MakxDekkers: On versioning, feedback from implementers has been positive
… Question for larger group is whether we provide multiple ways and leave to implementers....
AndreaPerego: We should probably sleep on this and find a way. to raise at the plenary
riccardoAlbertoni: Out of time now...