Re: Process Question: How to clean up meeting minutes

* Holger Knublauch <holger@topquadrant.com> [2017-01-06 09:41+1000]
> Thanks, Eric. I have attached the cleaned up minutes (mostly the attendees
> list was incorrect).

updated


> These minutes are ready for review by the group.
> 
> For future meetings I hope someone else can chair because I am not neutral
> enough on some topics. Unless anyone else volunteers, I will continue
> setting up the next meeting though, so that we can make progress.
> 
> Holger
> 
> 
> On 5/01/2017 21:31, Eric Prud'hommeaux wrote:
> >* Holger Knublauch <holger@topquadrant.com> [2017-01-05 21:07+1000]
> >>Does anyone on this mailing list know how to make (minor) corrections to the
> >>minutes (auto-generated from IRC) at
> >>https://www.w3.org/2017/01/04-shapes-minutes.html
> >><https://www.w3.org/2017/01/04-shapes-minutes.html>
> >If you have a replacement HTML, I can save it in-place.
> >
> >
> >>Thanks
> >>Holger
> >>
> 

> W3C
> 
> RDF Data Shapes Working Group Teleconference
> 
> 04 Jan 2017
> 
> See also: IRC log
> 
> Attendees
> 
> Present
>     AndyS, hknublau, simonstey, Nicky, Dimitris, TallTed, ipolikoff, dallemang
> Regrets
> Chair
>     hknublau (de facto chair in this meeting)
> Scribe
>     Dean Allemang
> 
> Contents
> 
>   • Topics
>      1. working group outlook
>   • Summary of Action Items
>   • Summary of Resolutions
> 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> 
> <hknublau> (Introductions by Nicky and Dean)
> 
> <AndyS> scribe: Dean Allemang
> 
> working group outlook
> 
> ipolikoff: Talked to Ralph Swick and Philippe Le Hegaret
> ... Process for extension is more difficult than it used to be
> ... W3C can do this up to 6 months without a vote process
> 
> ipolikoff: We can get this, but is not guaranteed. Mgmt wants to be assured we
> have resources to finish the work
> ... Make sure there are two independent implementations and test suite.
> Sometimes extension is specifically for test suite.
> ... They will discuss and decide during January.
> 
> ipolikoff: Discussion with TBL, to figure out how to make it succeed.
> ... there are new members to the group that Irene expects to see here
> ... possibly bringing in Mayo with a different rep
> 
> <simonstey> +q
> 
> hknublau: Last meeting before the holiday was unproductive, controversial
> discussions were not resolved.
> ... today's agenda attempts to address that.
> 
> <simonstey> -q
> 
> <hknublau> PROPOSED: Approve minutes of the 14 Dec 2016 Telecon: https://
> www.w3.org/2016/12/14-shapes-minutes.html
> 
> <AndyS> +1
> 
> <TallTed> +1
> 
> RESOLUTION: Approve minutes of the 14 Dec 2016 Telecon: https://www.w3.org/2016
> /12/14-shapes-minutes.html
> 
> AndyS: Give some perspective on current status of the group for new returned
> people dallemang and Nicky )
> 
> hknublau: for Language Features and Tech Details, the current spec is about
> where it is. Missing is precision and formality
> ... ... time is limited, we need to try to reach CR in the next month (or a
> couple more with extension)
> ... without extension, CR has to be done by end of Jan
> ... original timeline ends in June 2017
> ... SPARQL point in particular (ch. 5) into a separate doc
> ... SPARQL-based constraint compoinents are the basics of the spec (in hknublau
> 's opinion)
> 
> Dimitris: We are close to being done, but hknublau and Dimitris don't have
> experience with spec writing to finish the details that are needed
> 
> +q
> 
> scribe: Dimitris has a proposal to simplify things, which is some of our
> discussion points today
> 
> <ipolikoff> holger proposed splitting chp 7, 8 and 9 into a separate document
> that may or may not become a recommendation. But keep ch 5 and 6 (SPARQL
> constraints) in the main spec
> 
> -q
> 
> <ipolikoff> Dimitris is proposing splitting core from SPARQL
> 
> Dimitris: at the start, he wanted SPARQL as part of the main spec, but now sees
> two docs as a better chance for success.
> 
> <simonstey> +q
> 
> simonstey: Does this splitting really help our chances?
> 
> <ipolikoff> +q
> 
> +q
> 
> ipolikoff: hknublau's proposal is conservative; remove ch. 7-9 into a Note,
> lighten the spec and the workload
> ... issues on our list are overwhelmingly on the core, not on SPARQL
> ... prefer to go with hknublau 's proposal, cut things down, 7-9 to Note, 6
> remains, and see what happens in the CR
> 
> <hknublau> dallemang: I agree with Irene
> 
> <hknublau> ... Have many use cases, FIBO etc, I need a standard way to speak
> about the shapes of my data.
> 
> <hknublau> ... As a developer of semantic web standards, I prefer to write in
> SPARQL, RDF native. If chapter 5 would go away it would seriously damage our
> use cases.
> 
> dallemang: FIBO, GACS and SWISSPROT
> 
> Dimitris: clarifies that there is no proposal to throw 5-6 away, but put into a
> separate doc
> ... this would be a different CR
> 
> TallTed: Goal is "standards track" - first as note, track to becoming its own
> CR
> 
> ipolikoff: likely scenario is at least one (core) goes to CR. Then SPARQL part
> becomes a Note
> ... only reason to split is that we think that 1-4 will be successful, then 5-6
> is a separate doc (maybe note, maybe CR). We want it a CR, but it might end up
> as a note.
> 
> hknublau: SPARQL depends on core in current writeup
> ... If we split after section 4, making 5-6 a separate doc, so that it could
> make it on its own.
> 
> <simonstey> +q
> 
> hknublau: thinks that core has more problems than SPARQL
> 
> ipolikoff: thinks here customers are more intersted in SPARQL than in core
> (slightly)
> 
> dallemang: that is my interest
> 
> simonstey: core is a subset (functionality wise) of SPARQL
> 
> +q
> 
> simonstey: everything in core can be done in a SPARQL that does the same thing
> ... so we should aim at having SPARQL accepted
> 
> <hknublau> Summarize: 3 documents: SHACL Core (CR), SHACL SPARQL (5-6, CR),
> SHACL Full (7-9)
> 
> <simonstey> +q
> 
> dallemang: the spec is written the other way around; with "core" as the center,
> and SPARQL written as a commentary on that
> 
> simonstey: that was originally because we thought of multiple execution engines
> ... build semantics on SPARQL, which is not hte same as SPARQL constraints
> ... that story would be coherent, but it isn't how the group's work developed
> 
> Nicky: is it right to see 5-6 as an implementation of 1-4?
> 
> Dimitris: ch 4 is some built-in constraints, can they be done in pure sparql?
> ... If we want SPARQL stand-alone, then we'll have to repeat parts of sections
> 1-3 to define the language (e.g., target, constraint, shape)
> ... not so easy to have these as separate docs
> ... do we need 4 docs? One is core definitions, one for current core, one for
> SPARQL, and one for Full?
> 
> ipolikoff: asks for clarification of Dimitris ' breakdown?
> 
> Dimitris: Sections 1-3 in doc 1, 4 in second doc, 5-6 in third doc, 7-9 in
> notes
> 
> TallTed: there is a prejudice against RDF and SPARQL, even where you wouldn't
> expect it. That's a large piece of how we got to where we are.
> 
> <Dimitris> if we want both shacl full and shacl core as standalone language
> then we need more documents: shacl: sec 1-3, shacl core sect 4, shacl sparql/
> full: sec 5+
> 
> TallTed: In a sense it gives a draft implementation, but there is "fear of
> contamination"
> ... Starting from zero, if we started right now, maybe not true.
> 
> dallemang: This is apparent in the spec, where SPARQL is a possible
> implemention not definition
> 
> <Dimitris> but this is a very big load, shacl core (sec 1-4) and shacl sparql/
> full (sec 5+) that is based on core is more feasible and allows other langs
> like js
> 
> TallTed: the core could be SPARQL , but extensions could be in a new, hot
> language that isn't necessariliy SPARQL-based
> ... how do you leave that extension path open?
> 
> hknublau: Should we move forward on acting on one of these segmentation
> proposals?
> 
> <hknublau> STRAW POLL: Create two CR documents: SHACL Core (1-4) and SHACL
> SPARQL (5,6), and one WG Note (SHACL Full, 7-9)
> 
> <hknublau> STRAW POLL: Option 1: Create two CR documents: SHACL Core (1-4) and
> SHACL SPARQL (5,6), and one WG Note (SHACL Full, 7-9)
> 
> <hknublau> Option 2: Create one CR document: SHACL Core + SPARQL (1-6), WG Note
> (SHACL Full 7-9)
> 
> ipolikoff: It seems that Dimitris feels the need for a defintional umbrella, so
> that core and SPARQL can both draw on that.
> ... ask hknublau whether he thinks this is needed?
> 
> hknublau: this is almost an implementation detail
> 
> <simonstey> 1) 0 2) 1
> 
> hknublau: we can copy-paste the bits that are needed for whichever ones succeed
> 
> <Dimitris> splitting in 3 rec docs would be more risky
> 
> ipolikoff: has concern about having lots of documents
> 
> +q
> 
> Dimitris suggested "Dimitris: Sections 1-3 in doc 1, 4 in second doc, 5-6 in
> third doc, 7-9 in notes"
> 
> <hknublau> Option 3: Sections 1-3 in doc 1, 4 in second doc, 5-6 in third doc,
> 7-9 in notes
> 
> Should that be a poll option?
> 
> Dimitris: No
> 
> <Dimitris> a) +1 b) -0.5
> 
> <ipolikoff> 1) 0.5 2) 1
> 
> <hknublau> 1) 0 2) 1
> 
> dallemang: Can someone with more W3C experience comment on risks of having
> multiple docs?
> 
> <Nicky> a) +1 2) 0
> 
> AndyS: Change to rec track doc is a charter change; is this permissible?
> 
> ipolikoff: She believes that this was suggested during last meeting by Arnaud1
> 
> TallTed: Doesn't think this is a charter change
> 
> <Dimitris> https://www.w3.org/2014/data-shapes/charter
> 
> TallTed: this is timeboxed, not project completion boxed.
> ... Multiple docs is a nightmare. Changes in one has to be reflected in all of
> them, even when content is identical.
> ... changes that seem tiny turn into big ripples
> 
> 1) 0 2) 1
> 
> <TallTed> a: +1 b: +0.5 (really, I'm in favor of whatever the editors feel is
> achievable)
> 
> <ipolikoff> agree with Andy. In the end, it is whatever editors think is best
> 
> <hknublau> PROPOSAL: Split sections 7-9 into a separate document, likely a WG
> Note.
> 
> <ipolikoff> dallemang: wants SPARQL part
> 
> <hknublau> +0.5
> 
> <simonstey> +1
> 
> <ipolikoff> +1
> 
> <Dimitris> +1
> 
> +1
> 
> <ipolikoff> AndyS; we should let editors discuss and come back with a joint
> recommendation
> 
> <ipolikoff> hknublau: looked through the spec and convinced that splitting 7- 9
> is low impact
> 
> <TallTed> +1
> 
> <ipolikoff> dallemang: agrees that splitting 7-9 is easy and a good step
> 
> RESOLUTION: Split sections 7-9 into a separate document, likely a WG Note.
> 
> <simonstey> I can do that
> 
> <ipolikoff> hknublau: add something about rules to the WG Note
> 
> <hknublau> PROPOSAL: Make Simon an editor of the new WG note (with Holger)
> 
> <hknublau> +1
> 
> dallemang: is very strongly in favor of having rules written into the Note
> 
> <simonstey> +1
> 
> <ipolikoff> dallemang: supports adding a non normative section about rules
> 
> <Dimitris> +1
> 
> <TallTed> +1
> 
> +1
> 
> <ipolikoff> +1
> 
> RESOLUTION: Make Simon an editor of the new WG note (with Holger)
> 
> <ipolikoff> concerned about adding anything new given that we are out of time
> 
> <ipolikoff> dallemang: if there is something about rules that is already
> written, we could lift it without much work
> 
> <ipolikoff> hknublau: ISSUE-211, formal language is precise, but doesn't want
> to loose more informal descriptions, make them non normative
> 
> <ipolikoff> hknublau: two separate topics: formal language and simplifying
> metamodel, they are currently 2 different issues
> 
> +q
> 
> <hknublau> PROPOSAL: Reopen ISSUE-211
> 
> <ipolikoff> hknublau: proposes re-opening Issue-211
> 
> <hknublau> +1
> 
> <TallTed> +1
> 
> <simonstey> +1
> 
> <Dimitris> +1
> 
> <ipolikoff> dallemang: concerned about the editorial work that would happen
> with the change of the metamodel, it is unlikely we have time
> 
> <ipolikoff> +.05
> 
> +1
> 
> RESOLUTION: Reopen ISSUE-211
> 
> <ipolikoff> hknublau: this is a vote to re-open, not the vote for how to
> resolve it
> 
> <ipolikoff> hknublau: keep the prose as informative description, but also
> develop formal normative description
> 
> <ipolikoff> dallemang: isn't it what provenance WG did?
> 
> <ipolikoff> do the editors feel they have sufficient skills in writing in this
> mathematical style?
> 
> <ipolikoff> TallTed: would not recommend following provo example, it took a lot
> of work
> 
> <ipolikoff> Dimitris: thinks that change to the metamodel (Issue-211) should be
> resolved before it is decided to change the style of writing
> 
> <simonstey> +q
> 
> <ipolikoff> Dimitris: if we use Peter's writing, we need to confirm that he is
> OK with it
> 
> <ipolikoff> AndyS: because he sent it to the list, it should not be an issue
> 
> <simonstey> +q
> 
> <ipolikoff> Dimitris: He sent it to me personally, I sent it to the list
> 
> <ipolikoff> simonstey: agrees that we can't use Peter's writing without his
> explicit permission
> 
> +q
> 
> -q
> 
> <ipolikoff> +q
> 
> <simonstey> +q
> 
> <ipolikoff> hknublau: the only reason we are using the current style is because
> this was the previous editor's preference and also preferences of other WG
> members
> 
> <ipolikoff> AndyS: can Dimitris ask Peter to send his proposal to the mailing
> list?
> 
> <ipolikoff> Dimitris: I prefer someone else to do this
> 
> <ipolikoff> AndyS: I will ask Peter
> 
> <ipolikoff> dallemang: let's tackle issues
> 
> <hknublau> PROPOSAL: Close ISSUE-179 as out of scope (and out of time), e.g.
> leave it to Community Groups
> 
> <ipolikoff> +1
> 
> <hknublau> +1
> 
> <Nicky> +1
> 
> <simonstey> +1
> 
> <ipolikoff> TallTed: not out of scope, but very much out of time, in favor
> 
> <TallTed> +1 (fits with UI, so not out of scope, but definitely out of time)
> 
> RESOLUTION: Close ISSUE-179 as out of scope (and out of time), e.g. leave it to
> Community Groups
> 
> <hknublau> PROPOSAL: Close ISSUE-182 as addressed by the current spec (https://
> lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0056.html
> 
> <simonstey> issue-182
> 
> <trackbot> issue-182 -- Clarifications needed to section 3.0 -- open
> 
> <trackbot> http://www.w3.org/2014/data-shapes/track/issues/182
> 
> <hknublau> +1
> 
> <TallTed> +1
> 
> +1
> 
> <ipolikoff> +1
> 
> RESOLUTION: Close ISSUE-182 as addressed by the current spec (https://
> lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0056.html
> 
> <simonstey> -0.5
> 
> <ipolikoff> simonstey: we should not require that all validation results are
> required
> 
> <ipolikoff> hknublau: this was addressed
> 
> <simonstey> +1
> 
> <ipolikoff> hknublau: there is a branch, wants to make it into the main
> document
> 
> <ipolikoff> hknublau: it has a lot of simplifications, did anyone look at it?
> 
> <simonstey> I haven't looked at it
> 
> <ipolikoff> simonstey: postpone it to the next meeting to give people a chance
> to look at it
> 
> <hknublau> PROPOSAL: Close ISSUE-194 deleting sh:stem as rather useless (it is
> a short cut for sh:pattern which supports the use of regular expressions)
> 
> <simonstey> issue-194
> 
> <trackbot> issue-194 -- stems in value sets -- open
> 
> <trackbot> http://www.w3.org/2014/data-shapes/track/issues/194
> 
> <hknublau> +1
> 
> <ipolikoff> +.8
> 
> <simonstey> 0
> 
> <simonstey> http://w3c.github.io/data-shapes/shacl/#StemConstraintComponent
> 
> <simonstey> +q
> 
> <Nicky> +1
> 
> <ipolikoff> there are 3 proposals: keep as-is, drop, do something more
> comprehensive
> 
> <TallTed> +1
> 
> <ipolikoff> we are voting for drop right now
> 
> RESOLUTION: Close ISSUE-194 deleting sh:stem as rather useless (it is a short
> cut for sh:pattern which supports the use of regular expressions)
> 
> <ipolikoff> hknublau: what are the next step regarding the chair?
> 
> <ipolikoff> TallTed: W3C needs to appoint the rep that doesn't have conflicts
> 
> <hknublau> trackbot, end meeting
> 
> Summary of Action Items
> 
> Summary of Resolutions
> 
>  1. Approve minutes of the 14 Dec 2016 Telecon: https://www.w3.org/2016/12/
>     14-shapes-minutes.html
>  2. Split sections 7-9 into a separate document, likely a WG Note.
>  3. Make Simon an editor of the new WG note (with Holger)
>  4. Reopen ISSUE-211
>  5. Close ISSUE-179 as out of scope (and out of time), e.g. leave it to
>     Community Groups
>  6. Close ISSUE-182 as addressed by the current spec (https://lists.w3.org/
>     Archives/Public/public-data-shapes-wg/2016Oct/0056.html
>  7. Close ISSUE-194 deleting sh:stem as rather useless (it is a short cut for
>     sh:pattern which supports the use of regular expressions)
> 
> [End of minutes]
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> 
> Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
> $Date: 2017/01/04 15:04:07 $
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> 
> Scribe.perl diagnostic output
> 
> [Delete this section before finalizing the minutes.]
> 
> This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14
> Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
> 
> Guessing input format: RRSAgent_Text_Format (score 1.00)
> 
> Succeeded: s/dallenmang/dallemang/
> Succeeded: s/Philip ?? and/Philippe Le Hegaret and/
> Succeeded: s/and Jeff Philip//
> Succeeded: s/simonstey: if/dallemang: if/
> Found ScribeNick: dallemang
> Found Scribe: Dean Allemang
> Default Present: AndyS, hknublau, simonstey, Nicky, Dimitris, TallTed, .05, .8
> Present: AndyS hknublau simonstey Nicky Dimitris TallTed .05 .8
> 
> WARNING: No meeting chair found!
> You should specify the meeting chair like this:
> <dbooth> Chair: dbooth
> 
> Found Date: 04 Jan 2017
> Guessing minutes URL: http://www.w3.org/2017/01/04-shapes-minutes.html
> People with action items:
> 
> 
> [End of scribe.perl diagnostic output]


-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 6 January 2017 14:57:55 UTC