– DRAFT –
DXWG telecon

<riccardoAlbertoni> no sorry i am in a noisy place

kcoyle: first up approval of meeting meetings

Resolved: approve last week's minutes

kcoyle: reminder about face to face in Nov please sign up

meeting time

kcoyle: daylight savings and time zone changes are an issue for some

kcoyle: doodle poll will be emailed to group

alejandra: created a doodle poll and sent around as well

alejandra: doodle poll updated for week in November

<AndreaPerego> Thanks, Alejandra.

alejandra: can we use the one I created

<alejandra> https://‌beta.doodle.com/‌poll/‌n66t9dth6u5gfi2t

kcoyle: will look at alejandra's poll and respond as to next steps

kcoyle: note that the time for people in southern hemisphere, it's the next day. so can't include Friday because it will be their Saturday

kcoyle: only will be asking about Monday-Thursday in the doodle poll
… next checking open action items

Open action items

kcoyle: if anyone has an open action item that is included please let us know

Use Case Requirements

kcoyle: ended up with 2 points of view on one of the reqs
… DCAT need to decide what is vs. is not a version
… should this not be decided because communities already have decided on that

Jaroslav_Pullmann: agrees on the summary but can we look at the defintion of version which aspects of dataset should be consider which type of changes might indicate transition to a new version

kcoyle: question stands should be have a defintion
… wants a straw poll

<kcoyle> 1) need a definition 2) better not to define

<kcoyle> 0,0

<antoine> -1,+1

<Jaroslav_Pullmann> +1,-1

<annette_g> Wait, why two`/

<AndreaPerego> -1,+1

<riccardoAlbertoni> 0,1

<annette_g> I pick 2

<annette_g> -1, +1

<LarsG> 0,+1

<newton> 0,+1

<DaveBrowning> 0,+1

<Stijn_Goedertier_AIV> +1,0

DaveBrowning: i missed last weeks meeting and a bit behind

<Jaroslav_Pullmann> the "definition" would not define what a change is per se, but what aspects should be considered when judging if there is a "version"-alike change ..?

DaveBrowning: 2 weeks ago talked about having a version identifer is this question about that or some semantics that we apply to the identifer

<kcoyle> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Meetings:Telecon2017.10.09

kcoyle: Peter suggested wording for the first two requirements in versioning and during the discussion you can see his defintion is that we should specify what is vs. is not a version
… some in group did not agree

DaveBrowning: understands now given the recap

kcoyle: still a split in the group given voting
… so not sure how to resolve at this point may move on

alejandra: trying to think about what is the best thing
… if have a version need to decide what it is for
… looking at other ontologies, don't say how created but talk about previous versions
… maybe we should vote on a specific defintion, but not sure what mean by no definition
… if we talk about version we need something, it could be generic

kcoyle: Peter added two specific things - consider domain and range and provide illustrations when a new version would not be recommended - e.g. in de-duplication

<alejandra> as references, HCLS dataset description referred to versioning relying on PAV

<antoine> Tally: option 1: six 0s, one +1s, three -1s ; option 2: two 0s, seven +1s, one -1s (if I count well)

<alejandra> see the links: https://‌www.w3.org/‌TR/‌hcls-dataset/

kcoyle: agreee with what you say alejandra, but need wording we can vote on

<alejandra> https://‌pav-ontology.github.io/‌pav/

kcoyle: Peter's wording more specific than expecting

<alejandra> +1, I think we need some wording to be able to vote

kcoyle: if someone would like to propse alternative wording for what Peter has (in email) then please do that

annette_g: do think need to figure out answer to this
… suggest think about defining a list of types of versions
… i'm assigning this type of version to this
… it might be a middle ground
… example - there is a short of of 4 versions - is it a complete re-write, just changing a date, that type of thing, but not just amount of change
… there were 4 logical categories

kcoyle: so maybe we adopt that?

annette_g: yes.

alejandra: agree can find a middle ground
… need something broad enough so people can specify their own types of versions, so put a links on IRC see above

kcoyle: think we need to give someone the task of making a proposal
… alejandra annette_g anyone willing
… annette_g will propose something

<annette_g> Can you assign me an action for that?

Jaroslav_Pullmann: confusion now to indicate which properties are used other side the type of version is interesting to consumers of the dataset, should look at from point of view of client
… data didn't change but properties changed, what are they interested in with respect to the change?
… differentation with respect to type of change would be interseting
… not looking at how to indicate but which aspects should be consider when talking about a new version
… could propose a client oriented view regarding consumers/clients

kcoyle: sounds like what Peter was aiming at, so look at his response

<Stijn_Goedertier_AIV> * +1 to Jaroslav... For consumers, these could perhaps be interesting types of versions: language version, format version, revision to the content (minor corrections), revision to the API, major revisions to the content, ...

kcoyle: he says definition consideration should be given where creation of new version should not be recommended, but you would let people know what type of version should be created

Jaroslav_Pullmann: interested in evidence of change

kcoyle: annette_g is that something you could work in or should be give a separate action to Jaroslav

Jaroslav_Pullmann: we can sychrnoize

kcoyle: annette_g will put in email and then will be discussed via group

kcoyle: can we move on to other versioning reqs even though this issue isn't solved?
… talked above version identifer that we changed to indicator
… next requirement is Version Status

<kcoyle> https://‌docs.google.com/‌spreadsheets/‌d/‌16JmtNCz_aCWtTCSntriDWLvyPY2x-Y9dZFhAHFl55r0/‌edit#gid=0

kcoyle: sounds like Version Status will be very tied up with the identifer and defintition lets move to version release date

<kcoyle> 6.9.1

kcoyle: this is 6.9.1 in the google doc

Jaroslav_Pullmann: so the status is question how it would look
… assumption is if indicator not structured it would not provide hint of quality of current version
… so these are just examples

kcoyle: suggesting table Version Status

Jaroslav_Pullmann: Yes. Okay so release date, no question about the need to have this

kcoyle: anyone have anything else re: Version Release Date

annette_g: some people version things with date
… we would not want to say if have a date also need a version

kcoyle: we have not talked about requirements for that type. anyone else?

LarsG: if we want to make it easy data consumers probably need to have release date something they can sort on even if people use it as a version indicator

<annette_g> +1

LarsG: otherwise people would have to look at two things

<AndreaPerego> Re version release date, this can be simply modelled as the issue date of that version.

<kcoyle> PROPOSED: accept requirement 6.9.1 version release date

Ixchel: So is this wording good: 6.9.1 Indicate the date when specific version was created (released). The version identifier might refer to the release date.

<riccardoAlbertoni> +1

<AndreaPerego> 0

AndreaPerego: what do we mean with version release date seems like just the issue date

kcoyle: not sure understood the question

<Stijn_Goedertier_AIV> https://‌www.w3.org/‌TR/‌vocab-dcat/#Property:dataset_release_date

AndreaPerego: the creation, issue or last modify date so why need version release date if already have these others?

kcoyle: referring to dates already in DCAT?

AndreaPerego: yes, but thinking more conceptually.
… i would like to understand the proposal better because it is not clear

Jaroslav_Pullmann: i don't think there is a contradition. think they are equivalent release=issue date

LarsG: seconds that, especially considering release date re: link it IRC is the same thing

kcoyle: is it the same thing?

LarsG: andreaperego is the expert

<annette_g> +1 that they are the same

<AndreaPerego> [blushing]

kcoyle: if they are the same then do we need a release date

<alejandra> I agree with AndreaPerego - I don't think we need a version release date

<riccardoAlbertoni> +1 to Jaroslav_Pullmann

<alejandra> dates should be associated with the dataset, which will also have version information

Jaroslav_Pullmann: just needed to make requirements full/complete. agree already handled by DCAT, but should look at how handles versions in DCAT because not versions at the moment
… just a reminder to us. it might be already solved if use the same properties

kcoyle: is the suggestion that release date in DCAT would be renamed?
… right now these all say version.
… what would happen to release date

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

alejandra: just point to resources see link in IRC how divides summary level info see section 5
… there is a distinction re: date created it is not on the summary level but maybe we can take this approach

kcoyle: so saying unversioned release date would be made obosolete

alejandra: more about where to put the date summary or distribution

kcoyle: so if we accept this could the deliverable group work this out

alejandra: yes. at some point we need to resolve it, not sure at requirements level or development of the vocabulary level

kcoyle: can we pass it to the sub-group or is that cheating

Jaroslav_Pullmann: supports alejandra's view. dates are a property of the versions
… all resources which have a lifecycle that do change should have a property attached release or issue, not sure what to call it
… it's conceptual reference to temporal aspect of publishing a new version

annette_g: can the requirement be simplified, it must be possible to assign a date to a unqiue version and the group can run with that to see how it fits

kcoyle: so is that a rewording?

<AndreaPerego> +1 to annette_g

annette_g: yes. think so

<kcoyle> PROPOSED: accept 6.9.1 reworded: it must be possible to assign a date to a unique version

<annette_g> +1

<Jaroslav_Pullmann> +1

<LarsG> -1

<Stijn_Goedertier_AIV> +1

<alejandra> for reference, this is the old wording: "6.9.1 Indicate the date when specific version was created (released). The version identifier might refer to the release date."

<alejandra> +1

<DaveBrowning> +1

<antoine> +1

<AndreaPerego> "Identifier" or "indicator"?

<alejandra> I think it should be "indicator", as we decided two weeks ago

kcoyle: with this wording means group and decide to create a new date property or to rename the previous date property

LarsG: unsure of two things 1. the term summary level and 2. unique version
… if look at DCAT there is no summary level
… everything is versioned

<alejandra> the concept of "summary level" didn't come from DCAT, but from HCLS dataset description

LarsG: is that right?

<AndreaPerego> Yep.

<Zakim> LarsG, you wanted to ask if there is a "summary level"

alejandra: DCAT doesn't deal with version was refering to HCLS dataset description
… in case we think it is useful

LarsG: think it is extremely useful

<LarsG> +1

kcoyle: so willing to accept the new wording?

antoine: how doesn't mess with resolution
… just wanted to double check are there strong feelings re: word unique
… rewording mentions unique version. is unique needed?
… would we lose alot

<AndreaPerego> +1 to antoine

annette_g: maybe not just more clear talking at version and not distribution level
… not saying data is unique saying version is unqiue

kcoyle: would there be objections to dropping the word unique

annette_g: not sure what gaining with drop but thinks it still works

<kcoyle> ACCEPTED: accept 6.9.1 reworded: it must be possible to assign a date to a version

Resolved: accept 6.9.1 reworded: it must be possible to assign a date to a version

<annette_g> Thanks folks!

<AndreaPerego> Thanks, and bye!

<riccardoAlbertoni> bye thanks

<Jaroslav_Pullmann> bye

<LarsG> Cheers

<Stijn_Goedertier_AIV> thanks all, bye