– DRAFT –
Dataset Exchange Working Group Teleconference

<Caroline_> https://‌www.w3.org/‌2017/‌09/‌18-dxwg-minutes

Caroline_: can we approve last week's minutes?

<Caroline_> +1

Caroline_: no comments, so we can approve them

Resolved: Last week's minutes approved

<Caroline_> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Meetings:Telecon2017.09.25

Caroline_: today we want to approve the requirements based on Jaro's email

Caroline_: it would be good to decide as a group how to proceed with voting/approving the requirements

<Jaroslav_Pullmann> a second

Jaroslav_Pullmann: I looked at two options for numbering the requirements
… so I would like to discuss about this and resolve it
… option 1: continuous indexing, but it prevents easy collaboration
… option 2: grouping of requirements and number the groups
… this helps collaboration as different editors can work on different groups

kcoyle: this is somewhat complicated and I think it is best to discuss via email so that we can focus on the requirements today

Jaroslav_Pullmann: the action was on selecting a numbering scheme, so we did this and considered the options

Jaroslav_Pullmann: I'd like to spend a second to discuss about it

kcoyle: I don't think we are ready for this

kcoyle: we can consider the action completed

kcoyle: as there was so little discussion, we can ask people if they've looked at it

<Caroline_> alejandra: I think any of the options is okay

<Caroline_> ... as long there are numbers

<Caroline_> ... the other point would be making them more visible

<Caroline_> ... group the requirements

<Caroline_> ... we could even to investigate to do it with javascript

<Caroline_> ... to have a list where we can see all the requirements together

<Caroline_> ... it would be nice to have it at the end of the document

<Caroline_> https://‌www.w3.org/‌TR/‌dwbp/#requirements

Caroline_: what alejandra mentions, we did in the DWBP

+1, a summary table like that is useful

<Caroline_> Jaroslav_Pullmann:

Jaroslav_Pullmann: do you refer to a graphical grouping, where requirements are clustered

Caroline_: I included the link to the specific section

Caroline_: we need a review from the editors, not only from tagging

Caroline_: we need to have a review of the requirements

Jaroslav_Pullmann: what would we put in the left and right column?

Caroline_: grouping on the left and requirements on the right

Action: Jaroslav_Pullmann to create a tabular view on the requirements content

<trackbot> Created ACTION-42 - Create a tabular view on the requirements content [on Jaroslav Pullmann - due 2017-10-02].

kcoyle: it may be preferable to simple create a document
… the UCR group can decide how to do this, but I think that the point here is that we need a very human readable document
… whether or not can be automated or not, it is secondary
… we should aim at the most readable document possible, even it is not an automated process

Jaroslav_Pullmann: yes, what is preventing readability at the moment

kcoyle: the DWBP is clearer

Caroline_: can we approve the requirements based on Jaroslav_Pullmann' message

<Caroline_> Can we vote to approve the requirements as a group based on Jarosval email? https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-wg/‌2017Sep/‌0051.html

kcoyle: looking at last week's minute we had given Peter an action to rewrite the version definition requirement text

Caroline_: he's not on the call, we can ping him later

kcoyle: if we approve this, it will be pending to receiving that text

<Caroline_> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌open

kcoyle: it is on the minutes but not in the actions list - will add it now

annette_g: about versioning identifiers, I was wondering to what extent we want to be prescriptive about that
… it might be that we want to give some guidance about that
… for people that are versioning already, it may become a barrier to use DCAT if it doesn't follow their versioning scheme

<LarsG> annette_g: +1

annette_g: so I would suggest that we support multiple version schemes

Jaroslav_Pullmann: I'm referring to version identifiers
… to have a dependable logic where someone wants to identify versions of particular resources, they can do so
… this is not about the syntax of the identifiers

annette_g: I agree with the idea, the wording needs to be more precise

Jaroslav_Pullmann: it is not about the version or the value

annette_g: they are related, if someone is using semantic versioning, it is in the identifier

Jaroslav_Pullmann: we need to provide guidance on version identifier syntax

Jaroslav_Pullmann: three levels of versions, dates, etc
… this would be a recommendation
… but we don't prescribe what it goes in the identifier value

kcoyle: Antoine wrote this last time
… I think the problem here is the word 'identifier'
… we should limit the word to speaking about IRIs
… here it isn't saying that you would have an IRI for a version
… basically that there would be a clear statement of what the version is
… and we shouldn't use identifiers for that

<phila> (OWL uses version info)

annette_g: are you saying that the identifier for each version should be an IRI?

kcoyle: that is not what we want
… the word identifier is causing confusion

Jaroslav_Pullmann: the version is the resource

<LarsG> version designator?

Jaroslav_Pullmann: it is a resource that has been given a new revision/version

kcoyle: if you are saying that each version of a dataset would have an identifier, then it is not under versioning
… we already assume that each dataset will have an identifier

Jaroslav_Pullmann: I mean a version identifier
… a markup

kcoyle: markup is not an identifier
… markup is a description, not an identifier

kcoyle: we are assuming that every accesible dataset will have an IRI

<phila> OWL Version Information

<annette_g> HI Phil!!

phila: this discussion makes me look at OWL version info
… there are various annotation properties
… you can annotate an OWL ontology with different things about version
… and I think this might cover Jaroslav_Pullmann's point

<Daniele_B> Hi Phil :)

Jaroslav_Pullmann: what do you suggest for the wording?

phila: a human readable text
… essentially it is mean for humans, you can data type it
… this is orthogonal to the IRI of the dataset itself

kcoyle: we can call this version description

Jaroslav_Pullmann: yes, this is right

annette_g: for me description is text
… so I would be cautious to use 'description'
… maybe 'version name' or 'version identifier'

Caroline_: we should have a group decision on what to use

why not simply version?

<AndreaPerego> Just recalled that ADMS has a property for "version notes": https://‌www.w3.org/‌TR/‌vocab-adms/#adms-versionnotes

Jaroslav_Pullmann: we don't require this to be a number

Jaroslav_Pullmann: so 'version name' would be good

kcoyle: another term would be 'designation'

<Caroline_> https://‌www.w3.org/‌TR/‌dwbp/#dataVersioning

annette_g: it might be good to try to be consistent across documents with DWBP

so, 'version indicator'

Jaroslav_Pullmann: both 'version indicator' and 'version identifier' are used

<annette_g> +1 for indicator

<DaveBrowning> +1 for indicator\

+1 for indicator

<Caroline_> +1 for indicator

<AndreaPerego> If we use indicator, I would suggest we explicitly refer to the relevant DWBP BP, so readers have a clear definition of what we mean.

DaveBrowning: I think picking something for which people have preconceptions (like name or identifier) is not the best
… so I think that 'indicator' or 'designator' are the best options

Caroline_: so, we can vote on that

PROPOSED: use 'version indicator' and refer to the DWBP BP

+1

<AndreaPerego> +1

<Caroline_> +1

<LarsG> +1

<annette_g> +1

<DaveBrowning> +1

<Jaroslav_Pullmann> +1

<dsr> +1

<Stijn_Goedertier_AIV> +1

<Daniele_B> +1

<kcoyle> +1

<Ixchel> +1

Resolved: use 'version indicator' and refer to the DWBP BP

Caroline_: any other comment about the group of requirements for versioning?

kcoyle: we have 'version delta' for a description or a text
… describing what changed
… are we thinking that there would be some basic suggested ones?

Jaroslav_Pullmann: I think we could give some recommendation on it, and provide examples
… but I wouldn't prescribe the content of change management
… maybe collect best practices

<Caroline_> alejandra: if it is just a text describing is one think, I would remove that

Jaroslav_Pullmann: we thought about actions
… command-oriented formats
… indicating what has been changed

annette_g: I agree with Jaroslav_Pullmann, it should be flexible
… we cannot be prescriptive about it

<AndreaPerego> As I typed in earlier in the IRC, ADMS uses "version notes" for this purpose: https://‌www.w3.org/‌TR/‌vocab-adms/#adms-versionnotes

kcoyle: there are some common languages coming out of database environments
… with types of update files

<Jaroslav_Pullmann> thanks Andrea, adms:versionNotes is apparently only a text

kcoyle: it would be good to gather some examples of this

<AndreaPerego> Yep.

kcoyle: and include them in the document

annette_g: do you mean the actual SQL syntax?

kcoyle: no, I have to dig them up

<Caroline_> alejandra: the comment andrea sent As I typed in earlier in the IRC, ADMS uses "version notes" for this purpose: https://‌www.w3.org/‌TR/‌vocab-adms/#adms-versionnotes

<Caroline_> ... to mention semantics

<Stijn_Goedertier_AIV> A diff could be an example of a version delta. For example: https://‌github.com/‌w3c/‌dxwg/‌commit/‌1567da7ea2d71745e94951e611631b11af190c22#diff-47605d4269ba7b112b6a0f92a3f10d15

<Caroline_> ... if it is just a list of terms

alejandra: I think we should remove 'formal semantics' here

Stijn_Goedertier_AIV: I represent the Flemish Information Agency

<Jaroslav_Pullmann> fine, I'll do

Stijn_Goedertier_AIV: diffs allow you to see the changes and it could be an example of a version delta
… this is more formal than release/version notes
… and you would need a resource to describe it
… rather than some text

<Caroline_> For example: https://‌github.com/‌w3c/‌dxwg/‌commit/‌1567da7ea2d71745e94951e611631b11af190c22#diff-47605d4269ba7b112b6a0f92a3f10d15

Stijn_Goedertier_AIV: I also have a more general comment
… related to the first requirement on versioning
… the 'version subject'
… how the requirement is phrased now, it is solution oriented
… it is not phrased as a requirement
… it would be more helpful for the DCAT editors what is the real requirement
… what is the real subject
… datasets or different formats, different language versions
… how to represent it is something for the DCAT subgroup to figure out

Jaroslav_Pullmann: the subject is not only dataset, but also distributions or profiles

<Caroline_> alejandra: we want to version not only the dataset and other resources as well

<Caroline_> ... I agree with Stijn_Goedertier_AIV

<Caroline_> ... we should be looking into the use cases to define what requirements we have

<Caroline_> ... the requirement has to be specific. Ex. we need versions for...

<Caroline_> Jaroslav_Pullmann: I think this is to the DCAT group to decide

<annette_g> +1 to Alejandra

<Caroline_> alejandra: I think that should come from the use cases and the requirements should be specific by now

<Caroline_> +1 to alejandra

Stijn_Goedertier_AIV: it is up to us to specify the requirements
… there are several dimensions of versioning
… that we might put in this requirement
… for example you can version the metadata
… the requirement can be 'we want to version the metadata record'
… we shouldn't include the solution
… in the requirements

DaveBrowning: we can phrase requirements about the things that change without talking about changes in representation
… and then it becomes a requirement in the distribution change
… we can write the requirements in a way that don't directly refer to the solution
… even if that is what we've got on the back of our heads

annette_g: I'm not convinced that we need to consider versioning for the metadata itself
… where does it stop?
… we should stick to versioning datasets and distributions

Jaroslav_Pullmann: we should have a decision of this

<Stijn_Goedertier_AIV> +1 Annette (it was just an example of "version" dimension)

Jaroslav_Pullmann: what are the target resources that will have changes and for which we want to indicate those changes

<Caroline_> alejandra: I expect to find the versioning resources in the use cases we already have

<Caroline_> ... we should look for these answers on the use cases we have

Jaroslav_Pullmann: looking at the use cases, you have datasets and distributions

<kcoyle> PROPOSED: Go back to use cases to discover which resources need versioning, and create specific requirements

annette_g: I was going to say that a use case aims to limit what the actual requirements are

+1

<annette_g> +1

<Caroline_> +1

<Stijn_Goedertier_AIV> +1

<kcoyle> +1

<DaveBrowning> +1

<Ixchel> +1

<Jaroslav_Pullmann> +1

<dsr> +1

Resolved: Go back to use cases to discover which resources need versioning, and create specific requirements

Action: alejandra to go back to use cases to discover which resources need versioning, and create specific requirements

<trackbot> Created ACTION-44 - Go back to use cases to discover which resources need versioning, and create specific requirements [on Alejandra Gonzalez Beltran - due 2017-10-02].

<annette_g> Bye all!

bye and thanks!

<Daniele_B> thanks, see you next week

<Stijn_Goedertier_AIV> thanks and bye bye!

<AndreaPerego> Thanks, and bye!