See also: IRC log
<scribe> scribe: simonstey
RESOLUTION: Approve minutes of the 19 May 2016 Telecon: http://www.w3.org/2016/05/19-shapes-minutes.html
<marqh> me too
<Arnaud> PROPOSED: Open ISSUE-163, ISSUE-166
issue-163
<trackbot> issue-163 -- should "constraining" and other forms of "constraint" be used less in the specification -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/163
issue-166
<trackbot> issue-166 -- separate out advanced part of specification -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/166
<pfps> ./me I'll drop off and dial back in momentarily
<hknublau> +1
Arnaud: couple of non editorial questions that we may want to open
+1
scribe: relating to Tom's comments on the mailing list
<pfps> \me better
<Dimitris> +1
<marqh> +1
<pfps> +1
<kcoyle> +1
RESOLUTION: Open ISSUE-163, ISSUE-166
<hknublau> Response draft looked OK to me.
Arnaud: pfps drafted a possible response addressing Tom's comments
... but I haven't seen any comments to his proposed response
marqh: I had a look at the comments and think opening respective issues makes sense
<Arnaud> PROPOSED: Send Peter's proposed response as the WG's response to Tom's comments https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0224.html
+1
<pfps> +1
<marqh> +1
<Dimitris> +1
<hknublau> +1
<kcoyle> +1
RESOLUTION: Send Peter's proposed response as the WG's response to Tom's comments https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0224.html
<pfps> I'll send out the message.
Arnaud: I wanted to discuss that at last week's call already
... one of the advantages of publishing the document to the TR space is, that's stable, documented, and dated
... we should publish to TR space more often as we currently do
... I would like to hear from the editors what their point of view is
hknublau: I'm fine with publishing it now as it is
Dimitris: I agree with hknublau
... I would like to have some feedback on section 3
Arnaud: what do the other's think of publishing it now?
pfps: I just had a quick read-through the draft this morning and I'm not really happy as it is right now
... some repetitions, issues with the terminology section, etc.
jamsden: I think we missed an opportunity to publish the draft more often
... it's difficult to keep track of all the emails going on
... I think we should publish periodically
<kcoyle> no, ok for me
<pfps> The latest version of the SHACL spec is W3C Working Draft 28 January 2016. But in any case the WG is supposed to be reviewing the draft versions, not the WD versions. The WD versions are for *external* review.
marqh: I think publishing more often is a good idea
Arnaud: I think we should have some boilerplate text at the beginning of the document to make things clear
... i.e., that it's a moving target etc.
pfps: we aren't preparing WD for the WG
... the WG should review the ED
Arnaud: W3C used to require WGs to provide a heart beat every 3 months
... and we are way past that deadline now
<Arnaud> PROPOSED: Publish current SHACL editor's draft to TR space
<kcoyle> +1
<Dimitris> +1
Arnaud: we could also have certain parts of the document/issues highlighted just to make things more clear
+1
<marqh> +1
<hknublau> +1
<pfps> 0 The document is not very readable in its current state
<Labra> 0
<jamsden> +1
Arnaud: I think we should publish now and work hard to get a refined version out as soon as possible
marqh: I wanted to ask whether we should propose changes to e.g. paragraphs of the document directly in github
... where the editors can then decide whether they want to make it an issue
Arnaud: yes!
<kcoyle> uh oh!
RESOLUTION: Publish current SHACL editor's draft to TR space
issue-141
<trackbot> issue-141 -- How to represent mixed datatype-or-class ranges -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/141
Arnaud: last week we decided to postpone it
... I don't want to force this issue now; shall we postpone it as hknublau suggests since it's impacted by other issues?
<scribe> ... postponed!
issue-160
<trackbot> issue-160 -- Shall we generalize sh:valueShape to sh:shape -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/160
Arnaud: no one chimed in on the discussion at the proposals page
... pfps raised some concerns
<Dimitris> for me it is fine to generalize sh:valueShape
pfps: right now there are at least 3 descriptions of what valueShape actually does
... it's not clear on what of those the proposed generalization is based on
... such a generalization would further have implications of other parts of the section too
<pfps> Actually the first sentence of 4.1.1 sh:valueShape is currently incorrect.
marqh: is the text in the issue the complete text that needs to be changed?
... or is there more to it?
hknublau: the proposal is very brief
... I didn't create an extra branch for this issue
... we would only have to make two small changes
<Arnaud> PROPOSED: Close ISSUE-160, renaming sh:valueShape to sh:shape, adding sh:NodeConstraint to its context
<hknublau> +1
<Dimitris> +1
<kcoyle> +1
<pfps> There are similar problems for sh:minCount, sh:maxCount, sh:equals, and quite a few more.
<pfps> +1
<Labra> +1
+1
<jamsden> +1
<marqh> +1
RESOLUTION: Close ISSUE-160, renaming sh:valueShape to sh:shape, adding sh:NodeConstraint to its context
pfps: my remark is a follow-up on the first sentence of respective sections
... I think there's a utility in having a short description of what's going on
... as long as it's correct
kcoyle: what's the section number we're talking about
hknublau: e.g. 4.7.1
<Arnaud> http://w3c.github.io/data-shapes/shacl/#ValueShapeConstraintComponent
<pfps> 4.7.1 sh:valueShape
<pfps> The property sh:valueShape can be used verify that all values of the given property must have a given shape. The value type of sh:valueShape is sh:Shape, but the rdf:type triple of those shapes can be omitted.
Dimitris: we can either be very verbose or make up a new term for all those cases and use that
Arnaud: the editors should try to fix those parts as they progress
<pfps> In most cases, uising "value node" can produce a short, correct, informal description.
Arnaud: I want to make progress on all syntax related issues
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0080.html
Dimitris: the problem was that we have sh:constraint containing a group of constraint types
... e.g., nodeconstraint, sparql constraint, ...
... which might cause some problems if one wants to exclude certain constraint types
hknublau: I'm generally supportive of splitting it up
... e.g, using sh:constraint for nodeconstraints only (or even delete it at all) and spawn of another property for sparqlconstraints only
+q
<pfps> Dimitri's proposal retains the dual-control nature of constraint typing. A property constraint, for example, has SHACL type sh:PropertyConstraint but also sh:property is used only for property constraints. This dual control setup ends up being complex.
<pfps> Dimitri's proposal does eliminate some of the complexity.
hknublau: we could mark those properties, such that an engine could identify them
pfps: we have default types, explicit typing, and those properties for constraint typing
... and I think we should try to reduce the complexity
marqh: I think incremental regularizing is a step in the right direction
... makes things easier to comprehend
Dimitris: I don't have a clear solution to pfps's concerns
<pfps> The problem with incremental steps is that they often do not lead to the best solutions, only locally best ones.
<Arnaud> PROPOSED: Adopt Dimitris's proposed simplifications and regularizations descrbied in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0080.html
there are 2 aspects to 133
<marqh> is the proposal explicitly this: https://github.com/w3c/data-shapes/compare/editorial-dk?diff=split&name=editorial-dk
issue-131
<trackbot> issue-131 -- The definition of sh:hasShape has errors and holes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/131
whoops
issue-133
<trackbot> issue-133 -- syntax simplification and regularization -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/133
<Dimitris> PROPOSED: simplify sh:constraint and allow only sh:NodeConstraints, SPARQL constraints will be defined with a separate property
+1
<hknublau> +1
<Dimitris> +1
<kcoyle> 0
<pfps> 0 There are lots of better ways to simplify the syntax, including having only one property that links from shapes to constraints and distinguishing the different kinds of properties by their types.
<Labra> +0.5
<marqh> +1
RESOLUTION: Simplify sh:constraint and allow only sh:NodeConstraints, SPARQL constraints will be defined with a separate property
kcoyle: I don't think that just having "sparql" there isn't doing the trick
... it's not telling me that it's a constraint
<Dimitris> PROPOSED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask
pfps: by that logic sh:property & co would be affected too
<pfps> sh:property and sh:inverseProperty have the same problem as sh:shape
<kcoyle> +q
hknublau: there are pros and cons to this, I don't have a strong opinion on this
+q
<pfps> Similarly "property" already has an external meaning.
kcoyle: I agree that it could affect many others too, but if we use something like SPARQL.. I think it's very "nounish"
... I don't think we should use words that mean other things
simonstey: what about sh:native?
Dimitris: why not using sh:node and sh:sparql for now and raise an issue for potentially renaming them in the future
<Dimitris> PROPOSED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask. Rename sh:constraint to sh:node
<Dimitris> PROPOSED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask
0
<hknublau> +1
<Dimitris> +1
<kcoyle> +1
<pfps> 0
<Labra> 0
RESOLUTION: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask
Arnaud: if someone feels the need for renaming them, file an issue
hknublau: I think there was consensus on the scope renaming
... maybe we should tackle that next
<trackbot> issue-148 -- non-uniform syntax in scopes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/148
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-148:_Scope_declaration_simplification
hknublau: there are two aspects to it
... 1) change syntax of scopes, making it a single property
... 2) whether we still need allsubjects/allobjects scopes
<kcoyle> +q
<Arnaud> PROPOSED: For propertyScope and inverse property scopes, do not use sh:scope but the dedicated properties sh:scopeProperty and sh:scopeInverseProperty that point to a property directly. e.g. ex:shape sh:propertyScope ex:myPredicate .
<pfps> Except that SIP already has an external meaning.
kcoyle: those names don't make sense
[kcoyle and hknublau discussing about the meaning of the term scope]
<marqh> sh:scopeProperty and sh:scopeInverseProperty make sense to me
Dimitris: I'm with hknublau on this
kcoyle: there are those levels in the order of the workflow, and I think scoping and constraining makes sense
<Arnaud> PROPOSED: For propertyScope and inverse property scopes, do not use sh:scope but the dedicated properties sh:scopeProperty and sh:scopeInverseProperty that point to a property directly. e.g. ex:shape sh:propertyScope ex:myPredicate
<Dimitris> +1
kcoyle: but this seems more like constraining
<hknublau> +1
<kcoyle> .5
<pfps> +1, although the names don't work for me
<marqh> +1
+0.5
<Labra> +0.5
RESOLUTION: For propertyScope and inverse property scopes, do not use sh:scope but the dedicated properties sh:scopeProperty and sh:scopeInverseProperty that point to a property directly. e.g. ex:shape sh:propertyScope ex:myPredicate
+q
<Arnaud> wow
<Arnaud> somehow the meeting ended
<hknublau> Just as the tension was unbearable. Could you finish the sentence in writing?
<pfps> It's a sign from WEBEX!
<marqh> our time is up: webex has spoken :|
<Arnaud> is it just me?
no worries
my mistake
<Dimitris> I lost the interesting part of SImon's talk
<Arnaud> ok, that was very unfriendly from Cisco ;-)
<kcoyle> simon, can you finish your sentence?
I thought you proposed propertyScope rather than scopeProperty
my fault
<Arnaud> ok
<hknublau> Ok then.
<Arnaud> so, we will end the meeting on this then (have to!)
<hknublau> Bye.
<kcoyle> propertyscope at least is understandable as words
<Arnaud> thank you all for joining
<kcoyle> bye
<Arnaud> thank you simon for scribing
<Arnaud> talk to you next week
<Arnaud> hknublau and Dimitris, I will follow up on publishing the draft but I believe we should already be set with Echidna because we published 2 drafts
<Arnaud> the first one has to be published manually but the second one ought to have been published with Echidna
<Arnaud> I'll send an email
<Arnaud> trackbot, end meeting