<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!
Succeeded: s/he can ping/we can ping/
Succeeded: s/APPROVE/PROPOSED
Succeeded: s/Jaroslav_Pullmann: we have expressed on command actions/
Succeeded: s/RESOLVED Last week's minutes approved/RESOLVED: Last week's minutes approved/