W3C

– DRAFT –
DXWG Plenary

24 July 2018

Meeting Minutes

admin

<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

open actions

<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.

DCAT subgroup report

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!

Profile description subgroup

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

<kcoyle> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌ProfileRoundup#Proposed_Application_Profile_Guidance_document_outlines

<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

profile negotiation

ncar: I've commented on that in the previous section

UCR

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

Summary of Action Items

  1. ncar to update the README in the ProfileDesc directory to provide documentation and open a Github issue to begin discussion
  2. ncar to guide the guidance group to present some potential outlines

Summary of Resolutions

  1. accept minutes from last call
  2. 12.3 Requirement: one can create a profile of profiles, with elements potentially inherited on several levels.
  3. 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.
  4. 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.
Minutes formatted by Bert Bos's scribe.perl version 2.41 (2018/03/23 13:13:49), a reimplementation of David Booth's scribe.perl. See CVS log.

Diagnostics

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)