RDF Data Shapes Working Group Teleconference -- 04 Jan 2017

<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

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

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

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

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

<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

<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

<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

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

<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

<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

RDF Data Shapes Working Group Teleconference

04 Jan 2017

Attendees

Contents

working group outlook

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output