IRC log of shapes on 2016-06-02

Timestamps are in UTC.

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+
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
18:31:08 [pfps]
The other proposal is has (constraints and sometimes shapes) instead of constraints
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
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}
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 all{Predicates,Nodes} as well
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
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
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
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
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
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
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, kcoyle, TallTed, pfps, hsolbrig, present
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