<hknublau> PROPOSED: Approve minutes of the 04 Jan 2017 Telecon: https://www.w3.org/2017-01/04-shapes-minutes.html

<TallTed> trackbot: start meeting

<trackbot> Meeting: RDF Data Shapes Working Group Teleconference

<trackbot> Date: 11 January 2017

<hknublau> PROPOSED: Approve minutes of the 04 Jan 2017 Telecon: https://www.w3.org/2017/01/04-shapes-minutes.html

RESOLUTION: Approve minutes of the 04 Jan 2017 Telecon: https://www.w3.org/2017/01/04-shapes-minutes.html

<hknublau> scribenick: pano

WG Outlook

TallTed: Outlook much improved vs the previous month
...: [Summary of call with W3M]
... if we can make progress and make CR and handle the comments properly we have a shot at still making this a success

ipolikoff: we have till end of march for CR
...: W3M understands that we're working on important parts for the RDF community, and that's why they are considering this extension
... Annotate issues as at risk, when changes are made due to comments
... we do have to consider the public comments, and address them, but don't have to tackle it in line with the wishes of the commenter

<simonstey> +q

TallTed: We have to document the process of handling the comments, so that we can show W3M that we properly handled them.

simonstey: Did W3M say anything about the chairmanship?

TallTed: We are making efforts to try to get Arnaud back as chair. This is still in progress.

Dimitris' Draft

Dimitris: This was an effort to speed up the process

<simonstey> proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Jan/0015.html
...: shacl core is in good shape
... and i think the sparql semantics part can be separated into a different document

<ipolikoff> +q
...: so there are two specs: the shacl core, and the shacl sparql

ipolikoff: the document is quite formal and quite different from the current one
...: my preference would be to have one more descriptive document / tutorial, and one more mathematical/theoretic

<simonstey> primer?
...: i would like the spec to be written in a descripte style as it is now, and have a separate doc that specifies the mathematical parts

<ipolikoff> formal precision is a good thing and improval, but I would prefer it to be in one section at the end

<ipolikoff> have both the natural language text and mathematical precision in the document

<ipolikoff> agree with Simon that it is now less easy to read

simonstey: would it be beneficial to have the formal definitions to not be in sparql, but in a more abstract language? Because implementers with no knowledge of sparql might have a hard time to implement the spec
... but even with the time extension, this will be hard to achieve

TallTed: skimming over Dimitri's draft, I agree, the math is a lot. And I can imagine this will scare people off.

ipolikoff: this is why I would propose to put it in a separate section

TallTed: The problem is that that section would be the bulk of the document
... we could put the friendlier prose in the start of each section, and the formalisms at the end of each section

<AndyS> AndyS: SPARQL 1.0 was pushed into the users-then-formal style after the first Last Call.

<AndyS> ... it speaks to the implementers who want an exact, concise definition (e.g. why such and such a test does exacty what it does)

<AndyS> ... this is not what a general users wants or prefers.

<ipolikoff> +q

<AndyS> ... there are other styles but the tutorial-formal split was (for SPARQL) less work.

<ipolikoff> <TallTed> make sure that in moving too using the formal definition we have not changed what we had before

<TallTed> ack

ipolikoff: in removing the sparql definitions, are we impacting the implementers that would use sparql for implementing shacl in a negative way?

AndyS: I think separating explanation and definition is key here, explanations in sparql can still be helpful.

<simonstey> +q

simonstey: we had discussions about using sparql for formal definitions in the beginning of the WG, I believe this was an official resolution.

Dimitris: the current spec isn't fully defined in sparql

<TallTed> STRAW POLL: 1. shift to very mathematical (and no SPARQL); 2. add this (normative?) mathematical as section following (non-normative?) prose (including SPARQL examples); 3. revert to prose (including SPARQL examples)

TallTed: that's because we said we would sparql as much as possible

<simonstey> 4. a mix?

<ipolikoff> simonstey: we have decided previously to use sparql as much as possible

<simonstey> +q

hknublau: looking at this draft, I believe it invalidates about 50% of our previous resolutions... a lot for sure

simonstey: i mean 4. that we use the mathematical style for those parts that are not currently defined in sparql, but i think this would be hard to do

<TallTed> 1. -0.9 2. +1 3. -0.5

<AndyS> A/ doc style - two sections; tutorial-formal B/ (decisions) metamodel : orthogonal C/ SPARQL in core - pref use as examples, not definition.

hknublau: I would suggest some kind of a mix by adding more precision to the current draft where necassary. I think starting from section 4 the mathematical style would be cleaner
... I much prefer the sparql definition for things like minlength etc.

<ipolikoff> 1. -0.9 2. +.05 3. -0.5 4. +1

<hknublau> scribenick: ipolikoff

<simonstey> 1: 0.5 2: 1 3:-0 4: 0.5

<hknublau> 1. -0.9 2. 0 3. - 4: +1

<Dimitris> 1) +1 (enriching with examples) 2) 0, 3) -0.5

<pano> 1. -0.5 2. 0 3. -0.5

<simonstey> +q

simonstey: option 2 is easier to accomplish from the editorial perspective than 4

hknublau: not sure that option 2 is easier because we would need to keep the formalisms in sync

TallTed: we are clearly going for a blend, need to decide the best way to achieve it, this is largely the editorial question

AndyS: using a blend imposes limitations on the prose
... it is the editors call, but keeping the formalism all over the place will get push back from implementers

TallTed: can we use the current spec and add formalism as a section

hknublau: yes, this is good

<TallTed> PROPOSED: add Dimitris' formalized math draft as a section to the existing prose in progress; then work to align the sections

<hknublau> 0.5

+1

<TallTed> +1

<simonstey> +1

TallTed: it will be a lot of work, would have been easier if the formalism used the same notations

Dimitris: yes, it will be a lot of work

<Dimitris> -0.5 (too much work to have both like this)

<AndyS> +1

RESOLUTION: add Dimitris' formalized math draft as a section to the existing prose in progress; then work to align the sections

<AndyS> : we need to have the formalism in the spec, otherwise we will get a lot of push back, whether it is in line with the text or in a separate section

<simonstey> <-

Dimitris: should we have another editor? someone who has experience with writing formal math

TallTed: make a request to the working group to see who can help

<simonstey> +q

AndyS: help can come in reviewing sections for consistency

simonstey: I will help

ISSUE-211: Eliminate property constraints

<TallTed> PROPOSED: close ISSUE-216 with the resolution above -- i.e., we're mixing in the mathematical formalism

<hknublau> +1

<TallTed> +1

+1

<simonstey> +1

<AndyS> +1

RESOLUTION: close ISSUE-216 with the resolution above -- i.e., we're mixing in the mathematical formalism

<Dimitris> same as above -0.5 (too much work to have both like this)

<hknublau> PROPOSAL: Turn sh:property and sh:sparql into constraint components as described in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/0062.html

<hknublau> +1

hknublau: proposes an intermediate step to use the branch to make it easier to tackle 211

<TallTed> +1

+1

<Dimitris> +1 (if it does not affect the metamodel issue)

<Nicky> +1

<simonstey> +1

RESOLUTION: Turn sh:property and sh:sparql into constraint components as described in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/0062.html

hknublau: willing to make compromises

<hknublau> PROPOSAL 2: Generalize targets so that they apply to all shapes. Rename sh:PropertyConstraint to sh:PropertyShape. Rename its abstract superclass from sh:Constraint to sh:AbstractShape. Use the term "constraint" to refer to the use of parameters such as sh:minCount.

<TallTed> see https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-211:_Eliminate_property_constraints

<simonstey> +q

<simonstey> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0053.html

simonstey: what problems does the proposal solve?

hknublau: we have 2 very distinct concepts: shapes and property shapes (or property constraints), they can have different attributes

simonstey: is this implementation issue? I am still not seeing the major issue

Dimitris: the main issue is how much freedom we want to give users in writing shapes, do we want to restrict them and not allow them to write silly code

+q

Dimitris: also makes it easier to implement

TallTed: does your proposal eliminates the abstract superclass

<simonstey> http://w3c.github.io/data-shapes/shacl/#shapes

Dimitris: my proposal - everything is a shape, there are no constraints

TallTed: I have difficulty visualizing it, I would like to see them side by side

simonstey: what if there are node shapes and property shapes?

hknublau: could work, but breaks the existing syntax

simonstey: get rid of the property constraints to changes them into property shapes, but two sibling classes one called shape and another property shape is strange

hknublau: I don't have a problem with renaming shape class into node shape

TallTed: this will greatly help comprehension

hknublau: breaks examples, but I can live with it

<hknublau> PROPOSAL 2: Generalize targets so that they apply to all shapes. Rename sh:PropertyConstraint to sh:PropertyShape. Rename sh:Shape to sh:NodeShape. Rename their abstract superclass from sh:Constraint to sh:Shape. Use the term "constraint" to refer to the use of parameters such as sh:minCount.

+.5

<TallTed> +1

<hknublau> +1

<simonstey> +0.5

<Dimitris> +1 as long as the issue remains open

RESOLUTION: Generalize targets so that they apply to all shapes. Rename sh:PropertyConstraint to sh:PropertyShape. Rename sh:Shape to sh:NodeShape. Rename their abstract superclass from sh:Constraint to sh:Shape. Use the term "constraint" to refer to the use of parameters such as sh:minCount.

<simonstey> +1 for keeping it open

TallTed: need visualization to understand what remains in the issue

<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/att-0040/diagram.png

TallTed: present it in the wiki or e-mail in a pictorial way

hknublau: the other picture is node shape and property shape as siblings with the parent class shape

simonstey: we can make these changes as a result and pull in holger's branch and make the decision next week

hknublau: there will already be formal representation in the spec, with this, we do not need abstract syntax

ISSUE-177: Abstract Syntax is disconnected from concrete syntax

simonstey: can we utilize anything in the abstract syntax?

<hknublau> PROPOSAL 2: Close ISSUE-177 with no change before CR. Abstract syntax is currently not on the recommendation track. If WG has sufficient time and resources after reaching CR milestone and sees value in it, abstract syntax could be updated to become a more focused document, better sync up with the spec and be published as a WG note.

<hknublau> +1

+1

<TallTed> +1

<Dimitris> +1

<simonstey> +1

RESOLUTION: Close ISSUE-177 with no change before CR. Abstract syntax is currently not on the recommendation track. If WG has sufficient time and resources after reaching CR milestone and sees value in it, abstract syntax could be updated to become a more focused document, better sync up with the spec and be published as a WG note.

<hknublau> PROPOSAL: Close ISSUE-92 deleting sh:partition. QCRs provide sufficient coverage of the given use cases.

<simonstey> 0

<Dimitris> 0

Dimitris: should it be announced?

<hknublau> +1

+1

<TallTed> ADJOURNED

<TallTed> trackbot: end meeting

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)

Found ScribeNick: pano
Found ScribeNick: ipolikoff
Inferring Scribes: pano, ipolikoff
Scribes: pano, ipolikoff
ScribeNicks: pano, ipolikoff
Default Present: AndyS, Nicky, hknublau, TallTed, Dimitris, pano, .5
Present: AndyS Nicky hknublau TallTed Dimitris pano .5
Found Date: 11 Jan 2017
Guessing minutes URL: http://www.w3.org/2017/01/11-shapes-minutes.html
People with action items: