See also: IRC log
<Dimitris> cannot enter the call with webex
<Dimitris> the application keeps crashing
<Dimitris> android, linux doesnt work anyway :)
<ericP> yeah, codec prob
<scribe> scribenick: kcoyle
<Arnaud> PROPOSED: Approve minutes of the 14 July 2016 Telecon: http://www.w3.org/2016/07/14-shapes-minutes.html
RESOLUTION: Approve minutes of the 14 July 2016 Telecon: http://www.w3.org/2016/07/14-shapes-minutes.html
Arnaud: Comment on public list about "scope"
... thanks to Dimitris for responding
... do we have an answer other than Dimitris'?
hknublau: Sympathizes - scope is overloaded; suggest trigger, because place to start
<ericP> +1 to select
Dimitris: select or collect - nodes that are selected, e.g.
ericP: One issue is that spec uses this as the only way to select nodes - e.g. CSS selectors
... could be like API to select nodes
<hknublau> sh:selectorClass, sh:selectorNode, sh:selectorObjectsOf, sh:selectedSubjectsOf
kcoyle: "selector" comes from a different angle
Arnaud: illustration explains steps "scopes are used to select focus nodes" - define focus with a scope
<TallTed> maybe just "in focus" instead of "in scope"? sh:focusClass, sh:focusNode, sh:focusObjectsOf, sh:focusSubjectsOf
<Arnaud> sck kcoyle
<hknublau> @TallTed focus node already has a different meaning, at runtime.
kcoyle: had questioned "in scope" - which Dimitris has now removed
<TallTed> @hknublau - true...
Arnaud: "Selector" and "selected" seem to work in the text
<ericP> +1 to fixing
hknublau: we could respond that we are open to hearing suggestions; could create a ticket or wiki page where we talk about names
... requires more thought
Dimitris: select selectNode, selectObjectOf, etc.
<hknublau> This would benefit from being written down on a wiki page.
<Dimitris> e.g. selectNodes, selectInstancesOf, selectObjectsOf, selectSubjectsOf
Arnaud: asks Dimitris to answer / follow-up
... Dimitris to create wiki page and refer to it in email
ericP: Document is ok for a fpwd; has simplified view
Arnaud: (make this more obvious at the top of the document)
ericP: potentially out of scope as per use of path instead of inverse property scope
... does not have qualified cardinality restriction
Arnaud: needs references
Dimitris: also inverse property constraint, which is removed
Needs to coordinate with PWD of SHACL
hknublau: overlaps with what we already have; current document is more precise; there can be mis-matches
Arnaud: every new document is additional workload; but we decided to have an abstract syntax
... add a disclaimer that this is a complementary document to SHACL spec
<Dimitris> in the status it writes "This is a Working Draft. It is not decided whether this will be a WG Note or a WG Recommendation."
TallTed: 1) not yet decided if this is note, recommendation, appendix... non-normative. should be in the abstract. this is an AS drawn from core document
Arnaud: add that this is derived from SHACL
TallTed: should be 'non-normative" -
Arnaud: Note is non-normative by definition
... Eric will address this
... Do we need to republish SHACL? What changes have been done?
... maybe publish both at the same time
<Arnaud> you guys don't have any noise anymore?
<Arnaud> because I do!
hknublau: there are 2 more big syntax changes in the pipeline before republish
no, we don't hear it anymore, so it's you
<Dimitris> Agree with Holger
<ericP> [[ This Working Draft is an alternate representation of the SHACL specification. It is not decided whether this will be a WG Note, a WG Recommendation, or an appendix of the SHACL specification. ]]
kcoyle: does anyone else have examples? this would be used with flat data
hknublau: merging node constraint and shape
... just Topic 4 for now
kcoyle: what happens to non-sh comments in code?
Dimitris: shacl allows other properties; doesn't make a difference
... you can have other properties
<Zakim> ericP, you wanted to ask how i recognize an unknown "parameter" from an annotation property on the shape
ericP: challenge is that because you don't forbid additional properties you don't know a new parameter from an annotation property
... there are 3-4 things attached to a shape right now; but there are ~20 on a node constraint
... hard to know which things you need to pay attention to
Arnaud: also things like typos in the name - can warn about what is recognized
<hknublau> I don't think this is much different whether we merge the two or not.
<TallTed> ack q?
TallTed: 4 alternatives in this section, but only discussing 4a
hknublau: these four are not either/or - they all could be done (4a-4d)
jamsden: relating to OSLC resource shapes: a graph has nodes and edges; edges are properties
... you would think that constraints would follow that - node and property constraints
... how do they relate to each other? nodes and edges are organized by nodes and edges - what is the shape in this?
... it looks like shape also plays a role to constrain a node
hknublau: they do overlap, and that's one of the reasons to merge them - they both can have filter shapes
... a property constraint also starts at the node
... so it is easier to merge them
jamsden: thinking the same way, once concepts are covered, graph can contain node and property constraints; don't need something different for that
... all we need is graph as a container, a scoping mechanism, a node constraint, and a property constraint, to be combined with and/or/not
TallTed: looking at Wiki issue-133 page. Q: remove sh:constraint? but not obvious what else might be paralle to sh:constraint
... removing that container means that things in it become parallel to other things - what are those things?
hknublau: only other thing that shape defines is scopes (in SHACL)
TallTed: what other attributes might be applied to sh:closedShape that might cause a duplication because applies to node
hknublau: replace sh:constraint with sh:shape - can still use sh:shape in other places
TallTed: need to make the optionality clear
hknublau: e.g. constraints with different severities
Arnaud: we started with shapes, node constraints, property constraints - has a certain symmetry
ericP: a parllel between what is in a pth constraint and what is in a node constraint; if we merge node & shape, we save one triple
... and we mix models : shape has paths, and we mix with node constraints in one bag
... could be harder both for users and implementers
... most cost than value
Dimitris: agree with eric to says that shapes have scope and that contains constraints - although this is a syntax simplification, but I prefer not to do this
jamsden: property graphs are become popular for managing persistent data;
... graphs with nodes and edges; if we have a graph of data and graph of constrains, and both have nodes and edges
... this might allow use of shacl in graph databases
<Arnaud> STRAWPOLL: a) merge Shape and NodeConstraint, b) don't merge Shape and NodeConstraint
<hknublau> a: +1 b: 0
<jamsden> a: +1, b: 0
<TallTed> a +1 b -0.5
<ericP> a: -.5, b: .5
a) -.5 b) +1
<Dimitris> a) -0 b) +1
<pano> a: +1 b: 0
hknublau: keep extension mechanism as currently specified; but drop sh:context
Dimitris: proposal ok, with a minor change; ok to leave extension mechanism as is
Arnaud: do folks understand this compromise? (silence)
<Arnaud> PROPOSED: Close ISSUE-139, adopt Holger's compromise proposal https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0062.html
ericP: justification may not be accurate.... in 2nd paragraph of text of 139
<trackbot> issue-139 -- Can all constraint properties be applied in all scenarios? -- open
Dimitris: compromise is that we have universal applicability; with compromise on sparql extension, where it can be defined without universal applicability
... universal applicability but you can have more than one sparql query
RESOLUTION: Close ISSUE-139, adopt Holger's compromise proposal https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0062.html
<Arnaud> trackbot, end meeting