Meeting minutes
<riccardoAlbertoni> https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2020.06.03
proposed: accept minutes of last meeting https://www.w3.org/2020/05/20-dxwgdcat-minutes
<riccardoAlbertoni> +1
<AndreaPerego> +1
+1
proposed: accept minutes of last meeting https://www.w3.org/2020/05/20-dxwgdcat-minutes
Resolution: accept minutes of last meeting https://www.w3.org/2020/05/20-dxwgdcat-minutes
<riccardoAlbertoni> https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2020.06.03
Progress and feedback on the wiki page Material-for-a-SPRINT-on-Versioning
<riccardoAlbertoni> https://docs.google.com/spreadsheets/d/1kOp810ep3gQ2iezVXH-abX2q2QubqxNmyJ2bcX6WAFw/edit?usp=sharing
riccardoAlbertoni: I would like to point out the table
… it attempts to provide a summary of the background analysed on the wiki page
… it relates to the aspects AndreaPerego identified
… the diverse vocabs have some refinement. I started preparing an analysis but realised that we need more group discussion
… Colleagues can comment, and if you want to write to the table then that is possible - contact me
<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/92
riccardoAlbertoni: Moving to issues - #92 . about the identifier. We can get some agreement if we use owl:versionInfo
… Semantic Versioning is an option. It can work with owl:versionInfo
<AndreaPerego> +1
PWinstanley: in DCAT we used cardinal numbers for versions rather than the 3 decimal 'semantic versioning' . are we looking here only at the predicate, or also the object?
riccardoAlbertoni: if you look at the definition, it requires just a string - so you can put whatever you want. There is no enforcement of structure
… the suggestion of what to use is a matter of determining 'good practice'
<AndreaPerego> There's also https://www.w3.org/TR/vocab-adms/#adms-versionnotes
AndreaPerego: For the time-being, going into further depth with the way of identifying the version is not useful as this is community practice
… coming from ADMS there is another property - adms:versionNote that is complementary and allows the authors to document the version
PWinstanley: are there any good practices that we should embed in what we are working on here to fit with PAV or Prov-O. i.e. do we need to have either a string or an entity as the object?
riccardoAlbertoni: I don't think that we need to mint new terms.
… I think that prov provides enough for this. There is also some discussion about the point AndreaPerego mentioned before, the description of the difference.
… for example, other people would like to show the difference of a version using git style relations, but at the moment we should stick to the simple cases. We can provides some examples of practice and using more complex structures later
<riccardoAlbertoni> Proposed: Let’s include owl:versionInfo into DCAT for supporting version identifiers
<AndreaPerego> +1
+1
<riccardoAlbertoni> +1
Resolution: Let’s include owl:versionInfo into DCAT for supporting version identifiers
riccardoAlbertoni: do we want this in the normative part?
AndreaPerego: the main issue here is to understand where the versioning part will be published. If in the spec then it is a separate doc. In the primer then it could be in many potential places. But we can perhaps defer the decision
PWinstanley: if we go to putting it in the normative part of the spec we need good socialisation and community discussion before decisions
riccardoAlbertoni: we can, in the worst case, take the approach we did for DUV/DQV and refer to other docs
… but it could also go in the primer or somewhere else
AndreaPerego: I am still undecided, but if we put in the normative part then there is already implementation evidence
… one option is to keep it in the sections with guidelines, but it is also true that version information is important and I am not reluctant to have it in the normative part... There was discussion about the types of resources that can be version, but it isn't clear what the new version of a service means.
riccardoAlbertoni: I remember the discussion AndreaPerego referred to . At the time we discussed when writing dcat v2 we wanted to apply versioning to all the first class citizens of the model
… we need to discuss
AndreaPerego: if we are providing guidelines we need to work out what we mean. e.g. it might not be the service that is of a new version, it might be the interface using a new protocol
riccardoAlbertoni: maybe we can move on...
<riccardoAlbertoni> https://github.com/w3c/dxwg/issues/1238
<riccardoAlbertoni> Versioning and resource status:
versioning and resource status
riccardoAlbertoni: my impression is that adms:status can be a starting point. THe main concerns from PWinstanley are if we should use ADMS as a parent vocabulary. My view is that if we adopt adms:status then we can resolve the issues about namespaces etc later
<AndreaPerego> +1
PWinstanley: I haven't had time to consider with real-world data
<riccardoAlbertoni> http://www.opmw.org/model/OPMW
PWinstanley: the full life cycle of data needs to be able to be handled and this means having scope for extensive connections with descriptions of lineage, and workflow
AndreaPerego: the proposal makes sense for me. There is still discussion between makx and simon re: role of adms, but we can decide that later as we aren't proposing much other than adding adms:status. But what recommendation are we going to provide about it?
riccardoAlbertoni: I think we need to have a reference example, but also not restrict status indicators to the adms scheme alone. There are others. However, if we don't help people focus then we don't get interoperability
AndreaPerego: for people who know which status to use, they are not looking for guidance, but we need to help people who don't really know the territory that well
… There is implementation evidence already
PWinstanley: if we don't restrict status to a small number of options then we will end up with something similar to the situation with licenses where it is difficult to plan compatibilites
AndreaPerego: I see the point, and I'm also thinking that we need to also consider what status indicators might be used for. a user of the dataset should know if the dataset is stable or still under development. Internally, a data provider might require a different workflow for one dataset compared with another.
… e.g. staging vs prod
… so we need to look at it from more than a theoretical point of view
riccardoAlbertoni: I see the risk of speculating. One reason to consider expressing status is that there are already vocabularies there and we want DCAT to be the lingua franca across communities. for some of the problem we should stop at describing common practices. In some cases it might not be possible to go further.
… status can also be conflated with semantic versioning, but it is up to the community when to use one and when to rely on the other.
PWinstanley: being so flexible means that we cannot define a meaning then there is not much point in the predicate. it devalues the idea of a 'semantic' web
<riccardoAlbertoni> ack
AndreaPerego: I see the issue of interoperability, but status tends to be related to communities and it should be up to them to take this forward, perhaps with controlled vocabularies
riccardoAlbertoni: the part of versioning that is made up of relations between entities, a lot of ontological analysis is required to work out the version story and having appropriate bridges between communities is really helpful. Particularly, understanding which is the last version (most recent) is really worhtwhile
proposed: that adms:status is provisionally included as a working solution
+1
<riccardoAlbertoni> +1
<AndreaPerego> +1
Resolution: that adms:status is provisionally included as a working solution
bye
<AndreaPerego> Bye
<riccardoAlbertoni> bye