17:56:50 <RRSAgent> RRSAgent has joined #shapes
17:56:50 <RRSAgent> logging to http://www.w3.org/2016/06/02-shapes-irc
17:56:52 <trackbot> RRSAgent, make logs rdf-data-shapes
17:56:52 <Zakim> Zakim has joined #shapes
17:56:54 <trackbot> Zakim, this will be SHAPES
17:56:54 <Zakim> ok, trackbot
17:56:55 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
17:56:55 <trackbot> Date: 02 June 2016
17:58:38 <hknublau> hknublau has joined #shapes
17:59:54 <Arnaud> present+
18:00:05 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.06.02
18:00:08 <Arnaud> chair: Arnaud
18:00:25 <kcoyle> kcoyle has joined #shapes
18:01:44 <hknublau> present+
18:02:08 <kcoyle> present+
18:02:16 <Arnaud> regrets: jamsden, labra, dimitris
18:05:39 <TallTed> present+
18:06:54 <TallTed> scribenick: TallTed
18:08:41 <pfps> pfps has joined #shapes
18:08:44 <pfps> present+
<TallTed> topic: Admin
18:09:30 <Arnaud> PROPOSED: Approve minutes of the 26 May 2016 Telecon: http://www.w3.org/2016/05/26-shapes-minutes.html
18:09:47 <Arnaud> RESOLVED: Approve minutes of the 26 May 2016 Telecon: http://www.w3.org/2016/05/26-shapes-minutes.html
18:09:54 <pfps> minutes OK by me
18:10:29 <TallTed> topic: ISSUE-135 -- and/or syntactic sugar
18:11:05 <pfps> what has been changed so far?
18:11:22 <TallTed> Arnaud: what's missing to resolve this?
18:12:36 <TallTed> hknublau: this depends on ISSUE-133, discussion of sh:constraints syntax
18:12:40 <pfps> q+
18:12:57 <Arnaud> ack pfps
18:13:47 <hsolbrig> hsolbrig has joined #shapes
18:14:03 <hsolbrig> present+ hsolbrig
18:14:21 <ericP> -> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-135:_and.2For_syntactic_sugar issue 135 proposals
18:14:22 <TallTed> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-135:_and.2For_syntactic_sugar
18:14:22 <TallTed> pfps: there's a proposal to allow triple expressions.  does anyone aside from the proposer think that's relevant here?
18:15:27 <TallTed> ... that looks like a major change, and I wonder whether it solves this issue
18:16:27 <pfps> q+
18:17:35 <Arnaud> ack pfps
18:18:31 <TallTed> ericP: suggests this is an easy(?) way to make comprehensible nesting of ANDs, ORs, etc.
18:20:08 <pfps> A quick look at http://w3c.github.io/data-shapes/shacl/#OrConstraintComponent and the equivalent for sh:and would show that the same wording is used for the things that can go inside both and and or.  Admittedly there is not a real formal gramar for SHACL, but what is there is the same.
18:21:18 <pfps> The fact that a working group member is unsure what the top-level syntax for shapes is is a very bad sign for the working group.
18:22:43 <ericP> q+ to ask what a CLOSED inside a non-CLOSED means
18:23:04 <TallTed> hknublau: it seems that currently a shape is an intersection of constraints; we might also want to allow it to be a union; which would let everything fall together nicely...
18:23:31 <Arnaud> ack ericP
18:23:31 <Zakim> ericP, you wanted to ask what a CLOSED inside a non-CLOSED means
18:23:51 <pfps> The proposed syntax does not allow shapes to be embedded in other shapes - this is the MAIN difference.
18:25:01 <pfps> There are lots of other differences, such as requiring mins and maxs for every triple constraint
18:29:54 <pfps> The difference is that this proposal is shapes containing constraints containing constraints containing ...
18:30:19 <TallTed> ericP: one goal was to make CLOSEDness only a top-level, shape-level thing
18:30:25 <pfps> The current syntax is shapes containing constraints containing shapes containing constraints containing ...
18:30:57 <hknublau> q+
18:31:04 <Arnaud> ack hknublau
<TallTed> hknublau: I don't think this is actually really different than what we have in SHACL. I don't like the abstract grammar. I prefer we use RDF.
18:31:08 <pfps> The other proposal has (constraints and sometimes shapes) instead of constraints
<TallTed> Arnaud: I hope this has helped people understand the proposal, think about it, cast your vote on the proposals page
18:31:11 <TallTed> topic: ISSUE-148 -- non-uniform syntax in scopes
18:31:13 <marqh> marqh has joined #shapes
18:31:18 <Arnaud> issue-148
18:31:18 <trackbot> issue-148 -- non-uniform syntax in scopes -- open
18:31:18 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/148
<TallTed> Arnaud: we discussed this last week and addressed one of the two problems we have to address
<TallTed> ... let's talk about allsubject and allobjects scopes
18:31:20 <marqh> +present
18:32:58 <pfps> q+
18:33:03 <Arnaud> ack pfps
18:34:44 <pfps> So requiring SPARQL for scoping all nodes doesn't seem to be so bad for me.
18:35:03 <pfps> However, these were addded because someone wanted them.
18:35:39 <TallTed> hknublau: perhaps we should drop all{Subjects,Objects}
<TallTed> ... I haven't found them to be useful, last time Dimitris said he might have a use case but it wasn't clear
18:36:03 <kcoyle> q+
18:36:10 <Arnaud> ack kcoyle
18:36:16 <TallTed> pfps: if we have all{Subjects,Objects}, it seems we should have allNodes as well
<TallTed> hknublau: and allPredicates, where do you stop?
18:37:10 <TallTed> kcoyle: there wasn't a specific use case that spawned this, but there was a desire for a generalized broadened scope
18:37:32 <pfps> all dc:title literal can be done using property scopes
18:37:50 <pfps> q+
18:38:10 <Arnaud> ack pfps
18:41:30 <pfps> if you want decent validation messages then you would has a scope of all subjects of dc:title and then require of them that all their values for dc:title are literals
18:41:52 <ericP> q+
18:42:00 <Arnaud> ack ericP
18:43:11 <pfps> So I would be happy to completely remove these, but I would not be happy to have them just move to the advanced stuff
18:44:29 <TallTed> ericP: we have hasClass, which looks for rdf:type predicate with object of your specific...  maybe we want a template where you provide a predicate and either subject or object, which looks for everything in the missing position?
18:46:56 <Arnaud> PROPOSED: Delete AllObjectsScope and AllSubjectsScope from Core, leave this to be handled using the extension mechanism
18:46:59 <pfps> q+
18:47:04 <ericP> 0
18:47:06 <Arnaud> ack pfps
18:47:26 <hknublau> +1
18:47:40 <pfps> +1, as long as this syntax doesn't just end up in the advanced section
18:48:34 <kcoyle> +1
18:48:59 <TallTed> PROPOSED: Delete AllObjectsScope and AllSubjectsScope from Core, not to become Advanced.  Anyone who wants this functionality is left to write their own SPARQL.
18:49:16 <pfps> +1
18:49:20 <hknublau> +1
18:49:21 <hsolbrig> +1
18:49:25 <TallTed> +1
18:49:28 <kcoyle> +1
18:49:57 <ericP> +0
18:50:04 <Arnaud> RESOLVED: Delete AllObjectsScope and AllSubjectsScope from Core, not to become Advanced.  Anyone who wants this functionality is left to write their own SPARQL.
18:50:06 <hsolbrig> the identity vote
18:50:41 <Arnaud> PROPOSED: Close ISSUE-148, resolved given previous resolutions
18:50:47 <hknublau> +1
18:50:54 <TallTed> +1
18:51:06 <pfps> +1
18:51:09 <ericP> +1
18:51:09 <hsolbrig> +1
18:51:19 <kcoyle> +1
18:51:23 <Arnaud> RESOLVED: Close ISSUE-148, resolved given previous resolutions
18:51:31 <TallTed> topic: ISSUE-139 -- Can all constraint properties be applied in all scenarios?
18:51:31 <TallTed> ISSUE-139?
18:51:31 <TallTed> see https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-139:_Universal_applicability
18:51:31 <trackbot> ISSUE-139 -- Can all constraint properties be applied in all scenarios? -- open
18:51:31 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/139
18:52:57 <hsolbrig> pfps: vote must be a group
18:55:33 <TallTed> pfps: Bell Labs unix philosophy is to permit anything that might be reasonable, that doesn't actually cause problems, because it may become useful...
18:56:14 <pfps> q+
18:56:25 <pfps> q-
18:56:59 <pfps> q+
18:57:38 <TallTed> hknublau: some things have practical value/impact, e.g., hasValue has different impact as nodeConstraint than as propertyConstraint...
18:58:53 <Arnaud> ack pfps
18:59:17 <TallTed> Arnaud: we extended SHACL to address specific use cases, and wound up with many special case syntaxes.
18:59:17 <TallTed> ... pfps is suggesting making a simpler pattern, to be applied in multiple cases, which may lead to people doing "stupid" things, but that's no different than any other language...
18:59:59 <kcoyle> q+
19:00:18 <Arnaud> ack kcoyle
<TallTed> kcoyle: I think SHACL sometimes reads like a description of an implementation rather a language
<TallTed> ... if there are problems with implementation we should address these in notes or something specific to the implementation
<TallTed> kcoyle: ... but not make that part of the defination of the language
19:00:37 <pfps> It would also be nice to hear from someone who has implemented a SPARQL system that allows literals as subject.
19:01:01 <hknublau> q+
19:01:13 <Arnaud> ack hknublau
<TallTed> hknublau: it's not true that programming languages allow everything, there are all sorts of constraints like typing etc that limit the language
19:02:23 <kcoyle> q+
19:02:47 <Arnaud> ack kcoyle
19:02:56 <pfps> I don't believe that anyone is arguing that languages should allow everything.
19:03:37 <hknublau> q+
19:03:56 <Arnaud> ack hknublau
<TallTed> hknublau: of course it's possible to implement this in Core but how are we going to support this in the SPARQL exention?
19:09:51 <pfps> The particular case is known when the constraint component code is being generated.
19:09:54 <pfps> q+
19:10:09 <Arnaud> ack pfps
19:12:30 <TallTed> pfps: this proposal is just asking why have exclusions in this table of what can be done.  we do permit things like `AND (a, a)` which is obviously silly...  why go to the effort of forbidding other silly things?
19:12:43 <Arnaud> http://w3c.github.io/data-shapes/shacl/#constraints
19:17:36 <hknublau> q+
19:17:55 <pfps> q+
19:18:23 <pfps> q-
19:19:16 <Arnaud> ack hknublau
<TallTed> hknublau: my original point remains that I don't see any value in making this change which allows for meaningless constructs
19:21:17 <kcoyle> q+
19:22:15 <Arnaud> ack kcoyle
19:23:40 <TallTed> TallTed: testing whether `1 = 1` is silly, but every programming language lets you do it.  it causes no problem; it should be permitted.
19:25:11 <TallTed> TallTed: a generic syntax makes much easier for front-end users (possibly not for back-end developers).  unless it makes something near- or impossible, that generic syntax is worth striving for.
19:26:06 <hknublau> q+
19:26:08 <TallTed> s/impossible, that/impossible to implement, that/
19:26:17 <Arnaud> ack hknublau
<TallTed> hknublau: I think this is a mistake, it would move us backward rather than forward
19:27:33 <Arnaud> STRAWPOLL: Should we generalize the syntax along what peter is proposing to do with allowing constraint properties to be applied more broadly?
19:29:16 <hknublau> -1
19:29:25 <kcoyle> +1
19:29:43 <pfps> In SHACL it is already the case that things like sh:minExclusive have to handle things like ex:john > 1 because property constraints can have either IRIs or literals as value nodes.
19:29:45 <pfps> +1
19:29:56 <ericP> +1
19:29:58 <TallTed> +1
19:30:24 <marqh> ... 0
19:30:28 <kcoyle> harold's gone
19:30:51 <hknublau> Dimitris and Simon are missing too
<TallTed> Arnaud: the majority present seems to lean in favor of generalizing the syntax so we will need to spend more time on this
19:32:00 <Arnaud> trackbot, end meeting
19:32:00 <trackbot> Zakim, list attendees
19:32:00 <Zakim> As of this point the attendees have been Arnaud, hknublau, ericP, kcoyle, TallTed, pfps, hsolbrig, marqh
19:32:08 <trackbot> RRSAgent, please draft minutes
19:32:08 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/02-shapes-minutes.html trackbot
19:32:09 <trackbot> RRSAgent, bye
19:32:09 <RRSAgent> I see no action items