– DRAFT –
DXWG DCAT subgroup meeting

proposed: accept https://www.w3.org/2021/02/17-dxwgdcat-minutes

<alejandra> +1

<Makx> 0

<AndreaPerego> +1

+1

<DaveBr> +1 to minutes

Resolution: accept https://www.w3.org/2021/02/17-dxwgdcat-minutes

approve agenda

<AndreaPerego> +1

alejandra: we have an issue around software - including it as a resource type

<alejandra> https://codemeta.github.io/

alejandra: I think it is useful in relation to data, and the Force11 CodeMeta is mapping to schema, so I'll try for another crosswalk and I think we should add the properties they have compiles
… Same in the main as codemeta

+1 to alejandra

<Makx> +1

PWinstanley: we can add that to github and bring it into discussion in later meetings

range of locn:geometry

AndreaPerego:

AndreaPerego: this is an erratum. Feedback pointing out the inappropriate range (literal) rather than a class. literal was added because of bounding boxes and centroids, but the change will not break anything as locn:Geometry is an abstract class that allows most/all geospatial entities. The property helps specify any place, so flexibility is really needed
… If we put it in as an error then it is in the erratum page

alejandra: the comment by Simon about the Range - is there an issue?

AndreaPerego: here is the relevant bit...

<AndreaPerego> Definition of locn:geometry: https://www.w3.org/ns/locn#locn:geometry

AndreaPerego: the usage note shows it can be encoded as a literal or anything else - it's an abstract class, a placeholder
… so there is no restriction in the way that geometry can be represented

Versioning

AndreaPerego: one point is discussion about currentVersion and lastVersion - what they mean and how relevant they might be
… the prop :currentVersion is meant to point to a snapshot that represents the 'current' version. This prop should be used when versions of a resource are available and published sequentially - to indicate the current version. the other usage is with version chains where there are different snapshots
… when there is a URI that always points to the 'latest' version, and when there are resources evolving over time, :currentVersion points to the snapshot that is the current one of the moment

<alejandra> https://raw.githack.com/w3c/dxwg/dcat-versioning-v2/dcat/index.html#dataset-versions

AndreaPerego: There are diagrams in the draft document to help explain this

<AndreaPerego> https://raw.githack.com/w3c/dxwg/dcat-versioning-v2/dcat/index.html#fig-version-chain-and-hierarchy

during the meeting AndreaPerego presented the diagram and how it illustrated the rationale for the property

alejandra: what properties are not in PAV?

<AndreaPerego> What is not included in PAV is dcat:isVersionOf and dcat:hasLastVersion.

Makx: I have difficulty understanding why we are doing this. the explanation works on the basis of document versions, but I don't see the dataset case here because the URIs are not for datasets but are for duplicates of the same thing
… I would think that all we need (in the diagram) it pointers for the dcat2 - dcat3. With datasets it's just a duplicate identifier for the same dataset
… I think it would be easier to understand with :previousVersion and :nextVersion links
… I don't think :lastVersion is necessary

<AndreaPerego> Example of dataset: https://raw.githack.com/w3c/dxwg/dcat-versioning-v2/dcat/index.html#ex-version-chain-and-hierarchy

AndreaPerego: we have an example of a dataset - see link
… this is taken from DWBP
… a dataset and different snapshots of the same dataset
… In the versioning section we discuss, but we are not requiring - it is providing options that you have available

Makx: My recommendationis to stay to what PAV has and just have a link to the previous version

<alejandra> https://www.w3.org/TR/hcls-dataset/#datasetdescriptionlevels

alejandra: in the link for HCLS there is a reliance on PAV. I liked the figures shown earlier, but I think that because it focuses on a document example it missed some of the points that we might use if the example was relating to datasets
… in the HCLS we relied exclusively on PAV terms
… The other q relates to :isVersionOf
… do we need dcat, or could we use dct:

AndreaPerego: the reason we rely on PAV is that there is a more specific sense of version comparing than with dct.

alejandra: the only one I had doubts about was :isVersionOf

AndreaPerego: we are relying exactly on the PAV data model -
… the alternative is not to use the full PAV model
… the examples (I agree with alejandra and Makx that a dataset example would be good and I've started to add one).

alejandra: I agree that semantically it would be enough to have a chain of versions, but is it worth considering query performance and the computation of long property chains?

AndreaPerego: when creating a new version, are you going to alter the record of the previous dataset? This is really a metadata management decision.
… It can be done, but depends on policies etc for metadata management. We can mention these, but I wouldn't provide recommendations - this is an implementation issue
… also people can just pick up and use what they find useful
… Having use cases to work to would be helpful. This is just a draft for discussion, and needs testing

alejandra: thanks for the clarification. Situations where the rights to modification don't exist point to having this arrangement of props

<AndreaPerego> ADMS F/OSS: https://joinup.ec.europa.eu/sites/default/files/documentation/ADMS.FOSS_specification_v0.01.pdf

AndreaPerego: referring to the point about software raised earlier by alejandra , F/OSS might be a good starting point
… see link

AndreaPerego: there is a PR #927 which is a contribution relating to a Romanian translation
… this is parked and needs to be decided on - do we want to get an update from them

alejandra: can we include a partial translation? it is better than nothing

<AndreaPerego_> +1

<alejandra> thanks, and bye!

<DaveBr> bye

bye