<PWinstanley> https://www.w3.org/2018/07/17-dxwg-minutes
Proposed: accept minutes of last call
<kcoyle> +1
<azaroth> +1
<annette_g> +1
+1
<ncar> +1
Resolved: accept minutes from last call
PWinstanley: reminder to register to TPAC
… deadline for early bird is approaching
<PWinstanley> https://www.w3.org/2017/dxwg/track/actions/open
PWinstanley: 156 was finished and 146 was related
<ncar> re 148: I am still waiting for Lars to choose a time for profileneg before polling for a time for profile guidance. I have prompted him
PWinstanley: we agreed it doesn't cover comments but substantive parts of text
PWinstanley: is 94 done? Or is too far away in the past now?
dsr: if somebody can send me a pointer to the minutes I can do it.
<azaroth> link: https://www.w3.org/2017/dxwg/track/actions/145
<SimonCox> Minutes https://www.w3.org/2018/03/13-dxwg-minutes
PWinstanley: the other is to set up github so that it can be archived in W3C's repository
dsr: I can ask but I'm not sure what it entails.
… copying or cloning to give longevity guarantees
PWinstanley: yes
close action-146
<trackbot> Closed action-146.
close action-156
<trackbot> Closed action-156.
<SimonCox> But can we look at logs to see about rejected mails to comments
PWinstanley: there was also the issue of the public comment list
dsr: I've written Gerald about it, about lost feedback.
… not heard from him yet
<SimonCox> yes - there is a new post
PWinstanley: can we test?
… SimonCox confirms it works
<SimonCox> don't close until we've checked the logs?
PWinstanley: so we can close the action
dsr: the issue is that the queue was empty. It looks there was a problem identifying who submitted comments earlier.
PWinstanley: it's ok. It will be a good reminder for people
… thanks for resolving this
<ncar> re 148: Lars has actually now picked a time so I will now poll
<SimonCox> See this new mail in comments https://lists.w3.org/Archives/Public/public-dxwg-comments/2018Jul/0000.html
ncar: I was waiting for Lars to set a time. Now I'll mail the group/
PWinstanley: let's keep the action open
PWinstanley: we keep 110 open
PWinstanley: 129 Alejandra is not here
close action-155
<trackbot> Closed action-155.
PWinstanley: Now that we know we can't find lost emails we need to do comprehensive emailing
SimonCox: last week meeting was about tidying up smaller issues
… a PR about unstructured catalogues is still on top of the stack
… this is the big issue now
… Progress is reasonable, 4-8 people at meetings
… not enormous but it's the right number to make decisions
… I'm still making most of the contributions but I'll have to back up
… so I'm calling for others to be more involved now!
ncar: there's been a gap of meeting. Both Lars and I were away
… we're going to meet now that there's a new schedule
<roba> of course all welcome :-)
PWinstanley: we need to come with decisions/timing for deliverables.
ncar: we need the profile guidance group to meet
… we need the overarching view of what we do with profiles
… so that we know where the http conneg and the ontology sit
PWinstanley: at the plenary Lars said he would be unable to join.
… so we'll have to make sure communication works well
… possibly using the mailing list more.
kcoyle: I would like to set up some tasks so that the guidance group can start
… ncar to take an action to add the documentation for the profile description readme
… and create a github issue to make sure everyone understands
ncar: yes.
Action: ncar to update the README in the ProfileDesc directory to provide documentation and open a Github issue to begin discussion
<trackbot> Created ACTION-162 - Update the readme in the profiledesc directory to provide documentation and open a github issue to begin discussion [on Nicholas Car - due 2018-07-31].
kcoyle: the other thing is to submit for the plenary a selection of outlines for the profile guidance document
… I'm not sure what it's going to take
… but there are some proposals on github
… can it be done asynchronously?
<roba> * meta-guidance :-)
Action: ncar to guide the guidance group to present some potential outlines
<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.
PWinstanley: we need fairly close milestone
kcoyle: I could add them to the wiki page
PWinstanley: good idea
kcoyle: I'll set a milestone section
antoine: wasn't ncar's action about continuing the discussion on the big github issue
<ncar> The profile wiki Karen was refering to: https://www.w3.org/2017/dxwg/wiki/ProfileRoundup
<ncar> Snap Karen!
kcoyle: I have put two issues on the wiki page. ncar can start from there
<SimonCox> DCAT team is using milestones: https://github.com/w3c/dxwg/milestone/13 https://github.com/w3c/dxwg/milestone/4
antoine: about milestones, we had created projects on github
<SimonCox> DCAT group removed all other issue-based milestones last week
roba: we need consistency about groups.
<SimonCox> There remain a bunch of milestones around profiles ... https://github.com/w3c/dxwg/milestones
ncar: I've commented on that in the previous section
PWinstanley: is the PR issue ongoing?
https://lists.w3.org/Archives/Public/public-dxwg-wg/2018Jul/0078.html
AndreaPerego: still pending
roba: Jaro agreed to take this on in the last plenary
<PWinstanley> 12.3 Requirement: one can create a profile of profiles, with elements (constructs, axioms…) potentially inherited on several levels.
<roba> +1
annette_g: we need to figure out what 'inherited' means
kcoyle: it says what the solution is, but what is the problem
… why would one create a profile of profiles
roba: there were two use cases: Europeana and DCAT-AP
<AndreaPerego> Sorry, wrt my pending PRs, these have been actually merged by Jaro. Sorry for missing it - and, thanks, Jaro!
roba: GeoDCAT-AP as a profile of DCAT-AP which is a profile of DCAT
… we need to define them in a inherited way because of interoperability concerns
… ncar is doing it
<ncar> There is likely to be an Aust gov profile of DCAT that is then further profiled for particular govt sectors
<Zakim> azaroth, you wanted to briefly describe CIDOC-CRM -> linked.art -> exhibitions
<roba> +1
roba: we separate flattening from inheriting
antoine: two motivations: consistency and economy of building profiles
azaroth: another case: profiling CIDOC-CRM, selecting a part of it and then sub-profiling this selection for specific types of objects
annette_g: I want to be sure that we don't end up with people publishing long chains of profiles
… it could be hard to manage for humans
<roba> thats still implementation choice, whether such profiles are "packaged" flat - perhaps we need a UC that talks about the engineering issues
annette_g: since profiles may not be maintained by standardization bodies we could allow some laxity in how robust these links are
PWinstanley: it could be similar to what happens in object programming (e.g. Java libraries), where tooling help a lot.
<roba> machinery needs to handle version change detection...
kcoyle: consistency and economy of building profile make sense to me
… but there could be a difference between declaration and enforcing
… we could have to develop some pretty strict rules
PWinstanley: could rather than must or should?
kcoyle: I don't know any way except for code
<roba> +1 validation is an implementation choice - its bound up in contstrain language design
<roba> +1
kcoyle: roba it's true but we're not getting into implementation
<Zakim> azaroth, you wanted to assert inevitability of chains
kcoyle: how far could we go?
azaroth: on the chain issue: I think chains are inevitable.
… in DC and OAI-PMH, OAI-PMH had to create a 'record type'
… it's still a chain
… it's also happening in the ontology world
… we won't be able to prevent long chains with rules
… for documentation: doc and specs are different
… providing documentation can be done in one package.
… 'flattening" can be done in different ways
<kcoyle> antoine: 1) danger of chains: I agree with annette_g - but this issue also happens for a level 1 profile
<kcoyle> ... 2) kcoyle's on rules and enforcement: leave that to implementation level; validation language
<kcoyle> ... could enforce rules against profiles
<Zakim> SimonCox, you wanted to ask 'what is a standards organization'? and to ask 'what is a standards organization'? and whether we should prohibit all cases because of potential failures of a few
SimonCox: on earlier arguments about standardization. It sounds like "it might break so let's prohibit it"
… if it can be useful we shouldn't prohibit it, if chains exist conceptually
… likewise, we shouldn't restrict profiles to be produced by standard organizations. It's dangerous.
<AndreaPerego> +1
<PWinstanley> proposed: Accept 12.3 Requirement: one can create a profile of profiles, with elements (constructs, axioms…) potentially inherited on several levels.
roba: the requirement evidenced by the UC is straightforward. We can move the discussion to the Profile Guidance group
… there doesn't seem a disagreement.
<PWinstanley> proposed: Accept 12.3 Requirement: one can create a profile of profiles, potentially inherited on several levels.
<azaroth> +1
<ncar> +1
kcoyle: I would like to suggest that we say that one can create [...] leaving out the part "constructs, axioms...."
+1 even if I wrote it ;-)
<SimonCox> +1
<kcoyle> +1
<PWinstanley> +1
<riccardoAlbertoni> +1
<DaveBrowning> +1
<roba> +1
<AndreaPerego> +1
<annette_g> +1
Resolved: 12.3 Requirement: one can create a profile of profiles, with elements potentially inherited on several levels.
<PWinstanley> 12.4 Requirement: from the perspective of management of profiles, and guidance to users and data experts, ecosystems of profiles should be properly described (e.g. in profile catalogues/repositories), especially documenting the relationships between profiles and what they are based on, and between profiles that are based on other profiles.
<annette_g> +1 to that!!
<kcoyle> +1
<roba> needs to be shortened - the requirement is for a canonical way to describe relationships between profiles\
<AndreaPerego> +1 to stressing the documentation part
antoine: the first part is motivation, the second part is the gist
roba: completely agree. Not sure what is canonical. The requirement suggests that descriptions are interoperable
PWinstanley: it's about descriptions
<roba> -> the requirement is for an interoperable way to describe relationships between profiles
kcoyle: I hope we leave the 'ecosystem' in
… to me it was about documentation
<kcoyle> +1
PWinstanley: it could be about documenting the lack of exclusivity
<PWinstanley> proposed: accept 12.4 Requirement: from the perspective of management of profiles, and guidance to users and data experts, ecosystems of profiles should be properly described (e.g. in profile catalogues/repositories), especially documenting the relationships between profiles and what they are based on, and between profiles that are based on other profiles.
antoine: 'described' meant both machine-readbale and human-documented
<kcoyle> +1
<annette_g> +1
+1
<riccardoAlbertoni> +1
<AndreaPerego> +1
<PWinstanley> +1
<SimonCox> +1
<DaveBrowning> +1
<azaroth> +1
<ncar> +1
<roba> +1
Resolved: accept 12.4 Requirement: from the perspective of management of profiles, and guidance to users and data experts, ecosystems of profiles should be properly described (e.g. in profile catalogues/repositories), especially documenting the relationships between profiles and what they are based on, and between profiles that are based on other profiles.
<roba> rewording will be guidance group problem :-)
<PWinstanley> 12.5 Requirement: a profile should have human-readable documentation that expresses for humans the main components of a profile, which can also be available as machine-readable resources (ontology or schema files, SHACL files, etc). This includes listing of elements in the profile, instructions and recommendations on how to use them, constraints that determine what data is valid according to the profile, etc. [From the documents accessible from refe[CUT]
<ncar> +1
<AndreaPerego> Looks very similar to the previous one - should they be merged?
PWinstanley: is this in scope?
<roba> +1
<SimonCox> +1
<AndreaPerego> +1
<annette_g> +1
<DaveBrowning> +1
PWinstanley: AndreaPerego we don't mind if they are related. Main point is whether it's in scope
azaroth: including elements in a profile, is it a MUST?
<roba> "should" is our friend
PWinstanley: at the moment we can't determine
<AndreaPerego> Ack'ed, PWinstanley. It's in scope for me.
<azaroth> Propose to reduce to: a profile should have human-readable documentation that expresses for humans the main components of a profile.
<azaroth> Propose to reduce to: a profile should have human-readable documentation that expresses the main components of a profile.
kcoyle: it seems that what we need are the elements (necessary) of an AP
<azaroth> Propose to reduce to: a profile should have human-readable documentation that expresses its main components. (Sorry, keep shortening)
<kcoyle> +1 short is better
<AndreaPerego> azaroth, not sure. What people are looking for is full documentation on how to use profiles, including examples.
<roba> need to remember we have rejected previous deduplication and rewording - so the UCR needs to be rewritten after sub-groups have discussed wording...
PWinstanley: how do people feel about the shortening?
<azaroth> AndreaPerego: expresses at least its main components ?
PWinstanley: can I suggest to accept with a suggestion for re-writing
roba: about process. we're looking at UC, extracting requirements verbatim.
… last time I tried to merge things and it didn't work perfectly after
<riccardoAlbertoni> +1 to keep the requirement as it is
roba: so now we shouldn't look at perfect wording.
<annette_g> +1 to accept as is.
PWinstanley: yes we've made it clear
<kcoyle> +1
<roba> yep
<PWinstanley> +1
<riccardoAlbertoni> +1
<AndreaPerego> +1
Proposal: accept (maybe with tiny rewording) 12.5 Requirement: a profile should have human-readable documentation that expresses for humans the main components of a profile, which can also be available as machine-readable resources (ontology or schema files, SHACL files, etc). This includes listing of elements in the profile, instructions and recommendations on how to use them, constraints that determine what data is valid according to the profile, etc.
<SimonCox> +1
<azaroth> +0
<annette_g> +1
<AndreaPerego> +1
<riccardoAlbertoni> +1
<DaveBrowning> +1
+1
<roba> +1
<kcoyle> +1
<ncar> +1
<roba> * azaroth - "should" means requirement isnt strict ...
<Ixchel> +1
<SimonCox> yes, that's SHOULD which is recommended but not mandatory
Resolved: accept (with tiny rewording as part of UCR work) 12.5 Requirement: a profile should have human-readable documentation that expresses for humans the main components of a profile, which can also be available as machine-readable resources (ontology or schema files, SHACL files, etc). This includes listing of elements in the profile, instructions and recommendations on how to use them, constraints that determine what data is valid according to the profile, etc.
<azaroth> Agree "should" ... but should have human readable documentation, and then ... MAY / SHOULD / MUST ? list elements, etc
<riccardoAlbertoni> bye thanks a lot for the discussion
PW: adjourned
<AndreaPerego> Thanks, bye bye
Succeeded: s/ned/need/
Succeeded: s/reamin/remain/
Succeeded: s/anyway/any way
Succeeded: s/(maybe with tiny rewording)/(with tiny rewording as part of UCR work)