17:54:55 <RRSAgent> RRSAgent has joined #shapes
17:54:55 <RRSAgent> logging to http://www.w3.org/2016/05/26-shapes-irc
17:54:57 <trackbot> RRSAgent, make logs rdf-data-shapes
17:54:57 <Zakim> Zakim has joined #shapes
17:54:59 <trackbot> Zakim, this will be SHAPES
17:54:59 <Zakim> ok, trackbot
17:55:00 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
17:55:00 <trackbot> Date: 26 May 2016
17:55:16 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.05.26
17:55:19 <Arnaud> chair: Arnaud
17:56:26 <simonstey> simonstey has joined #shapes
17:57:50 <Dimitris> Dimitris has joined #shapes
17:58:11 <Arnaud> present+
17:58:29 <simonstey> present+
17:58:39 <marqh> marqh has joined #shapes
17:59:18 <Dimitris> present+
18:00:42 <marqh> present+
18:03:01 <jamsden> jamsden has joined #shapes
18:03:25 <pfps> pfps has joined #shapes
18:06:26 <simonstey> scribe: simonstey
18:06:40 <hknublau> hknublau has joined #shapes
18:06:42 <simonstey> topic: admin
18:07:16 <Arnaud> RESOLVED: Approve minutes of the 19 May 2016 Telecon: http://www.w3.org/2016/05/19-shapes-minutes.html
18:07:40 <marqh> me too
18:07:51 <hknublau> present+
18:07:53 <simonstey> topic: Disposal of Raised Issues
18:08:08 <Arnaud> PROPOSED: Open ISSUE-163, ISSUE-166
18:08:11 <simonstey> issue-163
18:08:11 <trackbot> issue-163 -- should "constraining" and other forms of "constraint" be used less in the specification -- raised
18:08:11 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/163
18:08:15 <simonstey> issue-166
18:08:15 <trackbot> issue-166 -- separate out advanced part of specification -- raised
18:08:15 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/166
18:08:18 <pfps> ./me I'll drop off and dial back in momentarily
18:08:51 <hknublau> +1
18:08:53 <marqh> q+
18:08:54 <simonstey> Arnaud: couple of non editorial questions that we may want to open
18:08:57 <simonstey> +1
18:09:12 <simonstey> ... relating to Tom's comments on the mailing list
18:09:13 <pfps> \me better
18:09:31 <Dimitris> +1
18:09:41 <marqh> +1
18:09:42 <pfps> +1
18:09:44 <kcoyle> +1
18:10:01 <Arnaud> RESOLVED: Open ISSUE-163, ISSUE-166
18:10:14 <simonstey> ?q
18:10:21 <simonstey> s/?q//
18:10:30 <simonstey> topic: Public comment
18:10:52 <hknublau> Response draft looked OK to me.
18:10:55 <simonstey> Arnaud: pfps drafted a possible response addressing Tom's comments
18:11:13 <simonstey> ... but I haven't seen any comments to his proposed response
18:11:39 <Labra> Labra has joined #shapes
18:11:41 <marqh> q+
18:11:49 <Arnaud> ack marqh
18:12:43 <simonstey> marqh: I had a look at the comments and think opening respective issues makes sense
18:13:13 <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
18:13:24 <simonstey> +1
18:13:27 <pfps> +1
18:13:28 <marqh> +1
18:13:32 <Dimitris> +1
18:13:40 <hknublau> +1
18:13:51 <kcoyle> +1
18:14:31 <Arnaud> RESOLVED: 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
18:14:45 <pfps> I'll send out the message.
18:15:10 <simonstey> topic: SHACL draft publication
18:15:37 <simonstey> Arnaud: I wanted to discuss that at last week's call already
18:16:43 <simonstey> ... one of the advantages of publishing the document to the TR space is, that's stable, documented, and dated
18:17:01 <simonstey> ... we should publish to TR space more often as we currently do
18:17:30 <simonstey> ... I would like to hear from the editors what their point of view is
18:17:43 <simonstey> hknublau: I'm fine with publishing it now as it is
18:18:03 <simonstey> Dimitris: I agree with hknublau
18:18:17 <simonstey> ... I would like to have some feedback on section 3
18:19:26 <pfps> q+
18:19:31 <Arnaud> ack pfps
18:19:33 <simonstey> Arnaud: what do the other's think of publishing it now?
18:20:20 <jamsden> q+
18:20:23 <simonstey> pfps: I just had a quick read-through the draft this morning and I'm not really happy as it is right now
18:20:26 <marqh> q+
18:20:53 <simonstey> ... some repetitions, issues with the terminology section, etc.
18:20:56 <Arnaud> ack jamsden
18:21:36 <simonstey> jamsden: I think we missed an opportunity to publish the draft more often
18:21:58 <simonstey> ... it's difficult to keep track of all the emails going on
18:22:21 <simonstey> ... I think we should publish periodically
18:22:39 <kcoyle> no, ok for me
18:23:08 <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.
18:23:18 <Arnaud> ack marqh
18:23:54 <pfps> q+
18:24:06 <simonstey> marqh: I think publishing more often is a good idea
18:24:21 <simonstey> q+
18:25:12 <Arnaud> ack pfps
18:25:15 <simonstey> Arnaud: I think we should have some boilerplate text at the beginning of the document to make things clear
18:25:37 <simonstey> ... i.e., that it's a moving target etc.
18:26:00 <jamsden> q+
18:26:02 <simonstey> pfps: we aren't preparing WD for the WG
18:26:18 <simonstey> ... the WG should review the ED
18:26:27 <Arnaud> ack simonstey
18:28:17 <Arnaud> ack jamsden
18:28:29 <simonstey> Arnaud: W3C used to require WGs to provide a heart beat every 3 months
18:28:42 <simonstey> ... and we are way past that deadline now
18:30:35 <Arnaud> PROPOSED: Publish current SHACL editor's draft to TR space
18:30:43 <kcoyle> +1
18:30:45 <Dimitris> +1
18:30:45 <simonstey> Arnaud: we could also have certain parts of the document/issues highlighted just to make things more clear
18:30:47 <simonstey> +1
18:30:48 <marqh> +1
18:30:54 <hknublau> +1
18:31:07 <pfps> 0 The document is not very readable in its current state
18:31:19 <Labra> 0
18:31:24 <jamsden> +1
18:31:38 <marqh> q+
18:32:02 <Arnaud> ack marqh
18:32:23 <simonstey> Arnaud: I think we should publish now and work hard to get a refined version out as soon as possible
18:33:23 <simonstey> marqh: I wanted to ask whether we should propose changes to e.g. paragraphs of the document directly in github
18:33:41 <simonstey> ... where the editors can then decide whether they want to make it an issue
18:33:47 <simonstey> Arnaud: yes!
18:34:02 <kcoyle> uh oh!
18:34:06 <Arnaud> RESOLVED: Publish current SHACL editor's draft to TR space
18:35:31 <simonstey> topic: issue-141
18:35:37 <simonstey> issue-141
18:35:37 <trackbot> issue-141 -- How to represent mixed datatype-or-class ranges -- open
18:35:37 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/141
18:35:51 <simonstey> Arnaud: last week we decided to postpone it
18:36:51 <simonstey> ... I don't want to force this issue now; shall we postpone it as hknublau suggests since it's impacted by other issues?
18:37:06 <simonstey> ... postponed!
18:37:11 <simonstey> topic: issue-160
18:37:16 <simonstey> issue-160
18:37:16 <trackbot> issue-160 -- Shall we generalize sh:valueShape to sh:shape -- open
18:37:16 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/160
18:37:46 <simonstey> Arnaud: no one chimed in on the discussion at the proposals page
18:38:28 <simonstey> ... pfps raised some concerns
18:38:32 <pfps> q+
18:38:32 <Dimitris> for me it is fine to generalize sh:valueShape
18:38:38 <Arnaud> ack pfps
18:39:34 <simonstey> pfps: right now there are at least 3 descriptions of what valueShape actually does
18:39:56 <simonstey> ... it's not clear on what of those the proposed generalization is based on
18:40:15 <hknublau> q+
18:40:26 <simonstey> ... such a generalization would further have implications of other parts of the section too
18:40:30 <Arnaud> ack hknublau
18:41:31 <pfps> Actually the first sentence of 4.1.1 sh:valueShape is currently incorrect.
18:41:34 <marqh> q+
18:42:01 <Arnaud> ack marqh
18:42:27 <simonstey> marqh: is the text in the issue the complete text that needs to be changed?
18:42:38 <simonstey> ... or is there more to it?
18:43:14 <simonstey> hknublau: the proposal is very brief
18:43:56 <simonstey> ... I didn't create an extra branch for this issue
18:44:11 <simonstey> ... we would only have to make two small changes
18:44:35 <Arnaud> PROPOSED: Close ISSUE-160, renaming sh:valueShape to sh:shape, adding sh:NodeConstraint to its context
18:44:40 <hknublau> +1
18:44:52 <Dimitris> +1
18:45:08 <kcoyle> +1
18:45:09 <pfps> There are similar problems for sh:minCount, sh:maxCount, sh:equals, and quite a few more.
18:45:13 <pfps> +1
18:45:18 <Labra> +1
18:45:18 <simonstey> +1
18:45:18 <jamsden> +1
18:45:19 <marqh> +1
18:45:35 <Arnaud> RESOLVED: Close ISSUE-160, renaming sh:valueShape to sh:shape, adding sh:NodeConstraint to its context
18:46:07 <hknublau> q+
18:46:29 <simonstey> pfps: my remark is a follow-up on the first sentence of respective sections
18:46:41 <Arnaud> ack hknublau
18:47:54 <simonstey> pfps: I think there's a utility in having a short description of what's going on
18:48:01 <simonstey> ... as long as it's correct
18:48:02 <Dimitris> q+
18:48:05 <marqh> q+
18:48:19 <simonstey> kcoyle: what's the section number we're talking about
18:48:20 <marqh> q-
18:48:36 <simonstey> hknublau: e.g. 4.7.1
18:48:36 <Arnaud> http://w3c.github.io/data-shapes/shacl/#ValueShapeConstraintComponent
18:48:37 <pfps> 4.7.1 sh:valueShape
18:48:39 <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.
18:49:12 <Arnaud> ack Dimitris
18:49:32 <simonstey> Dimitris: we can either be very verbose or make up a new term for all those cases and use that
18:50:19 <simonstey> Arnaud: the editors should try to fix those parts as they progress
18:50:24 <pfps> In most cases, uising "value node" can produce a short, correct, informal description.
18:50:30 <simonstey> topic: issue-133
18:50:56 <simonstey> Arnaud: I want to make progress on all syntax related issues
18:51:06 <Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0080.html
18:52:14 <simonstey> Dimitris: the problem was that we have sh:constraint containing a group of constraint types
18:52:24 <simonstey> ... e.g., nodeconstraint, sparql constraint, ...
18:52:59 <simonstey> ... which might cause some problems if one wants to exclude certain constraint types
18:53:15 <hknublau> q+
18:53:19 <Arnaud> ack hknublau
18:53:39 <simonstey> hknublau: I'm generally supportive of splitting it up
18:54:26 <simonstey> ... e.g, using sh:constraint for nodeconstraints only (or even delete it at all) and spawn of another property for sparqlconstraints only
18:54:29 <simonstey> +q
18:54:33 <Arnaud> ack simonstey
18:55:08 <hknublau> q+
18:55:22 <Arnaud> ack hknublau
18:55:54 <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.
18:57:07 <pfps> Dimitri's proposal does eliminate some of the complexity.
18:57:09 <pfps> q+
18:57:13 <simonstey> hknublau: we could mark those properties, such that an engine could identify them
18:57:14 <Arnaud> ack pfps
18:58:17 <simonstey> pfps: we have default types, explicit typing, and those properties for constraint typing
18:58:33 <marqh> q+
18:58:39 <simonstey> ... and I think we should try to reduce the complexity
18:59:09 <Arnaud> ack marqh
18:59:31 <simonstey> marqh: I think incremental regularizing is a step in the right direction
18:59:52 <Dimitris> q+
18:59:53 <simonstey> ... makes things easier to comprehend
19:00:10 <Arnaud> ack Dimitris
19:00:18 <simonstey> Dimitris: I don't have a clear solution to pfps's concerns
19:00:21 <pfps> The problem with incremental steps is that they often do not lead to the best solutions, only locally best ones.
19:01:48 <Arnaud> PROPOSED: Adopt Dimitris's proposed simplifications and regularizations descrbied in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0080.html
19:02:24 <simonstey> there are 2 aspects to 133
19:02:37 <marqh> is the proposal explicitly this: https://github.com/w3c/data-shapes/compare/editorial-dk?diff=split&name=editorial-dk
19:03:01 <simonstey> issue-131
19:03:01 <trackbot> issue-131 -- The definition of sh:hasShape has errors and holes -- open
19:03:01 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/131
19:03:07 <simonstey> whoops
19:03:11 <simonstey> issue-133
19:03:11 <trackbot> issue-133 -- syntax simplification and regularization -- open
19:03:11 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/133
19:03:26 <Dimitris> PROPOSED: simplify sh:constraint and allow only sh:NodeConstraints, SPARQL constraints will be defined with a separate property
19:04:02 <simonstey> +1
19:04:08 <hknublau> +1
19:04:11 <Dimitris> +1
19:04:20 <kcoyle> 0
19:04:31 <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.
19:04:39 <Labra> +0.5
19:04:41 <marqh> +1
19:05:23 <Arnaud> RESOLVED: Simplify sh:constraint and allow only sh:NodeConstraints, SPARQL constraints will be defined with a separate property
19:06:36 <kcoyle> q+
19:06:42 <Arnaud> ack kcoyle
19:07:12 <pfps> q+
19:07:18 <simonstey> kcoyle: I don't think that just having "sparql" there isn't doing the trick
19:07:37 <simonstey> ... it's not telling me that it's a constraint
19:07:40 <Arnaud> ack pfps
19:08:12 <Dimitris> PROPOSED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask
19:08:28 <simonstey> pfps: by that logic sh:property & co would be affected too
19:08:29 <hknublau> q+
19:08:33 <pfps> sh:property and sh:inverseProperty have the same problem as sh:shape
19:08:37 <Arnaud> ack hknublau
19:09:18 <Dimitris> q+
19:09:19 <kcoyle> +q
19:09:25 <Arnaud> ack Dimitris
19:09:34 <simonstey> hknublau: there are pros and cons to this, I don't have a strong opinion on this
19:09:43 <simonstey> +q
19:09:47 <Arnaud> ack kcoyle
19:10:35 <pfps> Similarly "property" already has an external meaning.
19:11:06 <simonstey> kcoyle: I agree that it could affect many others too, but if we use something like SPARQL.. I think it's very "nounish"
19:11:43 <simonstey> ... I don't think we should use words that mean other things
19:12:35 <Arnaud> ack simonstey
19:13:52 <Dimitris> q+
19:14:00 <simonstey> simonstey: what about sh:native?
19:14:22 <Arnaud> ack Dimitris
19:14:53 <simonstey> Dimitris: why not using sh:node and sh:sparql for now and raise an issue for potentially renaming them in the future
19:15:04 <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
19:15:17 <hknublau> q+
19:15:23 <Arnaud> ack hknublau
19:16:08 <Dimitris> PROPOSED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask
19:16:25 <simonstey> 0
19:16:25 <hknublau> +1
19:16:32 <Dimitris> +1
19:16:36 <kcoyle> +1
19:16:40 <pfps> 0
19:16:43 <Labra> 0
19:17:09 <Arnaud> RESOLVED: sparql constraints will be defined with the sh:sparql predicate and rename the existing sh:sparql to sh:select and sh:ask
19:17:39 <hknublau> q+
19:17:40 <simonstey> Arnaud: if someone feels the need for renaming them, file an issue
19:17:46 <Arnaud> ack hknublau
19:18:23 <simonstey> hknublau: I think there was consensus on the scope renaming
19:18:45 <simonstey> ... maybe we should tackle that next
19:18:26 <simonstey> topic: ISSUE-148
19:18:26 <trackbot> issue-148 -- non-uniform syntax in scopes -- open
19:18:26 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/148
19:19:16 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-148:_Scope_declaration_simplification
19:19:06 <simonstey> hknublau: there are two aspects to it
19:19:22 <simonstey> ... 1) change syntax of scopes, making it a single property
19:19:36 <simonstey> ... 2) whether we still need allsubjects/allobjects scopes
19:20:55 <kcoyle> +q
19:21:04 <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 .
19:21:09 <Arnaud> ack kcoyle
19:22:24 <pfps> Except that SIP already has an external meaning.
19:22:36 <hknublau> q+
19:22:43 <Arnaud> ack hknublau
19:22:50 <simonstey> kcoyle: those names don't make sense
19:24:55 <simonstey> [kcoyle and hknublau discussing about the meaning of the term scope]
19:25:27 <Dimitris> q+
19:25:40 <Arnaud> ack Dimitris
19:26:02 <marqh> sh:scopeProperty and sh:scopeInverseProperty make sense to me
19:26:29 <simonstey> Dimitris: I'm with hknublau on this
19:28:15 <simonstey> kcoyle: there are those levels in the order of the workflow, and I think scoping and constraining makes sense
19:28:24 <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
19:28:35 <Dimitris> +1
19:28:36 <simonstey> ... but this seems more like constraining
19:28:37 <hknublau> +1
19:28:47 <kcoyle> .5
19:28:49 <pfps> +1, although the names don't work for me
19:28:52 <marqh> +1
19:29:08 <simonstey> +0.5
19:29:16 <Labra> +0.5
19:29:28 <Arnaud> RESOLVED: 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
19:29:48 <simonstey> +q
19:29:55 <Arnaud> ack simonstey
19:30:13 <Arnaud> wow
19:30:23 <Arnaud> somehow the meeting ended
19:30:36 <hknublau> Just as the tension was unbearable. Could you finish the sentence in writing?
19:30:36 <pfps> It's a sign from WEBEX!
19:30:37 <marqh> our time is up: webex has spoken :|
19:30:38 <Arnaud> is it just me?
19:30:43 <simonstey> no worries
19:30:45 <simonstey> my mistake
19:30:56 <Dimitris> I lost the interesting part of SImon's talk
19:31:00 <Arnaud> ok, that was very unfriendly from Cisco ;-)
19:31:06 <kcoyle> simon, can you finish your sentence?
19:31:26 <simonstey> I thought you proposed propertyScope rather than scopeProperty
19:31:30 <simonstey> my fault
19:31:35 <Arnaud> ok
19:31:36 <hknublau> Ok then.
19:31:55 <Arnaud> so, we will end the meeting on this then (have to!)
19:31:59 <hknublau> Bye.
19:32:02 <kcoyle> propertyscope at least is understandable as words
19:32:05 <Arnaud> thank you all for joining
19:32:15 <kcoyle> bye
19:32:21 <Arnaud> thank you simon for scribing
19:32:23 <Arnaud> talk to you next week
19:33:05 <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
19:33:35 <Arnaud> the first one has to be published manually but the second one ought to have been published with Echidna
19:33:42 <Arnaud> I'll send an email
19:35:54 <Arnaud> trackbot, end meeting
19:35:54 <trackbot> Zakim, list attendees
Po19:35:54 <Zakim> As of this point the attendees have been Arnaud, simonstey, Dimitris, marqh, hknublau, kcoyle, pfps, jamsden, Labra
19:36:02 <trackbot> RRSAgent, please draft minutes
19:36:02 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/26-shapes-minutes.html trackbot
19:36:03 <trackbot> RRSAgent, bye
19:36:03 <RRSAgent> I see no action items