IRC log of shapes on 2016-01-21

Timestamps are in UTC.

18:58:11 [RRSAgent]
RRSAgent has joined #shapes
18:58:11 [RRSAgent]
logging to
18:58:13 [trackbot]
RRSAgent, make logs rdf-data-shapes
18:58:13 [Zakim]
Zakim has joined #shapes
18:58:15 [trackbot]
Zakim, this will be SHAPES
18:58:15 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
18:58:16 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
18:58:16 [trackbot]
Date: 21 January 2016
18:58:31 [Arnaud]
18:58:36 [Arnaud]
chair: Arnaud
18:58:47 [Arnaud]
regrets: hsolbrig
18:58:50 [Arnaud]
18:59:50 [hknublau]
hknublau has joined #shapes
19:00:51 [Arnaud]
present+ kcoyle, simonstey, ericP
19:02:05 [pfps]
pfps has joined #shapes
19:02:09 [Dimitris]
Dimitris has joined #shapes
19:02:10 [pfps]
19:02:42 [aryman]
aryman has joined #shapes
19:02:50 [aryman]
present+ aryman
19:03:16 [Labra]
Labra has joined #shapes
19:04:58 [hknublau]
19:05:59 [kcoyle]
kcoyle has joined #shapes
19:06:13 [kcoyle]
present+ kcoyle
19:07:26 [Labra]
present+ labra
19:08:07 [Dimitris]
19:08:12 [TallTed]
19:08:21 [TallTed]
scribenick: TallTed
19:08:24 [Arnaud]
PROPOSED: Approve minutes of the 14 January Telecon:
19:08:34 [Arnaud]
RESOLVED: Approve minutes of the 14 January Telecon:
19:08:38 [pfps]
Looked OK by me
19:09:24 [TallTed]
topic: UCR draft
19:10:30 [TallTed]
Arnaud: are we ready?
19:10:46 [TallTed]
kcoyle & simonstey: think so...
19:11:06 [Arnaud]
PROPOSED: publish the latest UCR Editor's draft
19:11:21 [pfps]
I think that UCR is OK to go (I only did a quick glance, but I don't see any issues).
19:11:36 [kcoyle]
19:11:38 [aryman]
19:11:39 [TallTed]
19:11:43 [Labra]
19:11:43 [pfps]
19:11:43 [Dimitris]
19:11:43 [simonstey]
19:12:03 [ericP]
19:12:16 [hknublau]
19:12:30 [Arnaud]
RESOLVED: Publish the latest UCR Editor's draft
19:14:23 [TallTed]
Arnaud: let's talk about Karen's questions,
19:15:40 [TallTed]
kcoyle: I did a review of UCR vs current spec, and flagged the things I couldn't clearly match
19:16:06 [TallTed]
Arnaud: seems best to stay with email for this for now; please everyone take a look!
19:20:00 [TallTed]
topic: ISSUE-22: recursion,
19:20:10 [pfps]
I believe that the document reflects the recent resolution on recursion.
19:20:21 [pfps]
However, I do not think that ACTION-29 has been completed.
19:22:01 [hknublau_]
hknublau_ has joined #shapes
19:22:18 [TallTed]
aryman: spec disallowed recursion. more recently we've been exploring some ways to allow it in certain circumstances, but spec'ese of this has not yet been done
19:23:09 [hknublau]
hknublau has joined #shapes
19:23:50 [TallTed]
[ discussion echoing aryman ... ACTION-29 remains open ]
19:24:43 [TallTed]
topic: ISSUE-23: ShapeClass,
19:25:19 [TallTed]
s/ACTION-29 remains/ACTION-29 and ISSUE-22 remain/
19:26:24 [TallTed]
aryman: in the course of updating for issue-23, I discovered another issue...
19:27:16 [TallTed]
... determination of Class/subClass looks to data graph in some places and shape graph in others
19:27:41 [pfps]
19:28:04 [TallTed]
... this needs some additional clarity if not consistency
19:29:52 [TallTed]
... computing shapes graph is up to application calling validator, so it seems pulling such Class triples from data graph should be easily done there, if needed
19:29:55 [Arnaud]
ack pfps
19:30:25 [TallTed]
... SHACL validator probably shouldn't be made to do this
19:31:10 [hknublau]
19:32:06 [TallTed]
pfps: class-based reasoning is very complicated, and has to be explicitly covered if it's to be part of SHACL processor implementation
19:32:18 [ericP]
q+ to say that the SPARQL approach is to work over ground facts, which may be a "virtual" product of inference
19:34:27 [TallTed]
aryman: right, so calling application should pull all { $x a rdfs:class } and { $a rdfs:subClassOf $b } triples into shape graph
19:34:30 [TallTed]
pfps: not enough
19:34:54 [Arnaud]
ack hknublau
19:35:30 [TallTed]
hknublau: I think that `scopeClass` and `shapeClass inference` are different; shouldn't be thrown together
19:35:45 [TallTed]
... person creating shapes will often be different than person using those shapes
19:35:53 [aryman]
19:37:03 [TallTed]
... so explicit class declarations must be left to the shape creator
19:37:15 [Arnaud]
ack ericP
19:37:15 [Zakim]
ericP, you wanted to say that the SPARQL approach is to work over ground facts, which may be a "virtual" product of inference
19:37:28 [TallTed]
... pulling 50,000 class definitions (in one real ontology) across is not viable
19:38:26 [aryman]
19:39:37 [Arnaud]
ack aryman
19:40:14 [TallTed]
aryman: pfps's objections apply to what existed before as much as revision
19:40:41 [TallTed]
... question is currently which graph is used to determine whether something is an rdfs:Class or not
19:41:03 [TallTed]
pfps: I thought the only thing that mattered was class membership in the data graph
19:41:16 [TallTed]
... that now seems not to be so
19:42:11 [TallTed]
... the current thread says that much I would consider to be outside the data graph comes into play
19:42:44 [hknublau]
19:42:57 [TallTed]
... current issue is the requirement to determine whether a shape is also a class.
19:44:09 [TallTed]
aryman: issues arise because we chose to describe our shapes using RDF, making it possible to do shape-class reasoning over the shape graph
19:44:31 [Arnaud]
ack hknublau
19:44:32 [TallTed]
... we can simply state that *all* class-based reasoning must be based entirely on the data graph
19:45:53 [TallTed]
hknublau: anyone creating a shape definition can just import any relevant ontology, to inherit such class defs
19:46:36 [TallTed]
pfps: there might not be an ontology graph to import. such is not required by any other spec. relying on it is thus problematic.
19:47:23 [aryman]
19:47:35 [TallTed]
hknublau: a person writing shape definition knows which classes they're talking about, so can import, create, or whatever as needed
19:47:46 [Arnaud]
ack aryman
19:49:05 [pfps]
19:49:24 [TallTed]
aryman: the inconsistency I thought I was seeing is minor, and can be easily addressed without changing spec substantially
19:49:42 [Arnaud]
ack pfps
19:50:34 [TallTed]
pfps: as far as I can tell, SHACL doc is inconsistent. in different places, it says to look at different evidence to make what appears to be the same determination.
19:51:39 [TallTed]
... the existing inferable inconsistency is better than making it an explicit inconsistency.
19:52:13 [pfps]
the spec needs to be changed so that it has a clear specification of how to handle the various class-related questions
19:52:31 [pfps]
19:52:39 [Arnaud]
ack pfps
19:52:40 [aryman]
fyi we are taking about
19:54:35 [aryman]
19:55:14 [Arnaud]
ack aryman
19:55:17 [aryman]
I will change that to say "If a resource X is both a shape and a class ..."
19:56:40 [pfps]
changing behaviour is not word smithing!
19:56:41 [TallTed]
[ pfps and aryman discuss possible rewording to resolve concern ]
19:57:11 [aryman]
"If a resource X in the shapes graph is both a shape and a class ..."
19:57:40 [TallTed]
topic: ISSUE-115: ClosedShape,
19:58:15 [aryman]
19:58:31 [Arnaud]
ack aryman
19:58:56 [TallTed]
Arnaud: reconsideration of resolution may be appropriate, looking at
19:59:02 [pfps]
19:59:09 [Arnaud]
ack pfps
19:59:34 [TallTed]
aryman: resolution seems OK, might mean we need a couple new things to address these concerns
19:59:44 [pfps]
if shapes can have severity then use that severity for closed violations
20:00:56 [TallTed]
hknublau: I believe there are real use cases where closedness will be applicable to part but not all of a given shape, or within context of a filter
20:01:21 [hknublau]
ex:MyShape sh:constraint sh:Closed .
20:01:30 [hknublau]
ex:MyShape sh:closed true
20:02:32 [hknublau]
ex:MyShape sh:constraint [ sh:closed true ]
20:03:07 [aryman]
20:03:31 [TallTed]
... previous setup allowed for many user-friendly shortcuts, which resolution disallows
20:03:47 [Arnaud]
ack aryman
20:04:20 [simonstey]
ignore property thingy
20:04:29 [TallTed]
aryman: this nuance about rdf:type -- under what circumstances can we ignore rdf:type?
20:04:57 [hknublau]
ex:MyShape sh:constraint sh:ClosedIgnoringRDFTYpe .
20:05:49 [TallTed]
hknublau: it's not an existing special case, but it could be, and I believe would be valuable
20:07:25 [pfps]
20:07:51 [TallTed]
TallTed: I'm inclined to the reconsideration
20:07:54 [Arnaud]
ack pfps
20:08:22 [TallTed]
Arnaud: if it were just me, I feel inclined to to bow to hknublau's arguments
20:09:49 [TallTed]
pfps: doesn't feel like a good solution to me. closure can't be determined locally.
20:09:49 [TallTed]
... have to look at all constraints associated with ... the shape the constraint is attached to.
20:09:49 [TallTed]
... and what happens if this is beneath an `and` constraint.
20:09:50 [TallTed]
... this doesn't act entirely like a constraint, so we shouldn't treat it like one
20:10:25 [aryman]
20:10:32 [Dimitris]
if we have severity at the shape level, then all shape constraints can inherit the shape severity (unless they override it)
20:10:34 [Arnaud]
ack aryman
20:10:38 [TallTed]
... all that said, it won't cause decline and fall of Roman Empire to be so treated
20:12:08 [TallTed]
aryman: it might be the case that the author wants to know about extra properties, but they won't break everything
20:15:43 [aryman]
sh:closed sh:Hopefully
20:16:03 [simonstey]
sh:closed sh:mostly
20:19:03 [Arnaud]
PROPOSED: Change Rersolution of ISSUE-115 to have sh:closed on sh:constraint instead of sh:Shape
20:20:28 [Arnaud]
PROPOSED: Change Rersolution of ISSUE-115 to have sh:closed on sh:NodeConstraint instead of sh:Shape, and define sh:Closed as syntactic sugar
20:20:45 [Arnaud]
PROPOSED: Change Resolution of ISSUE-115 to have sh:closed on sh:NodeConstraint instead of sh:Shape, and define sh:Closed as syntactic sugar
20:20:53 [hknublau]
20:20:54 [TallTed]
20:20:56 [simonstey]
20:21:01 [aryman]
20:21:11 [pfps]
20:21:13 [ericP]
20:21:14 [kcoyle]
+0 but I believe Holger
20:21:16 [Labra]
20:21:19 [Dimitris]
20:21:43 [Arnaud]
RESOLVED: Change Resolution of ISSUE-115 to have sh:closed on sh:NodeConstraint instead of sh:Shape, and define sh:Closed as syntactic sugar
20:23:08 [hknublau]
20:23:22 [pfps]
With those two changes I think that the draft can go out.
20:23:35 [kcoyle]
20:23:38 [Arnaud]
ack hknublau
20:24:16 [aryman]
I will update the text for ISSUE-23 today
20:24:36 [hknublau]
I will handle sh:closed today
20:24:47 [TallTed]
topic: SHACL draft
20:24:52 [Arnaud]
ack kcoyle
20:25:30 [TallTed]
[ previous PWD incorrect mailing list has been fixed ]
20:26:15 [TallTed]
[ let's try to publicize better this time, try to drum up more public review and response ]
20:27:21 [pfps]
Sending something to the appropriate W3C mailing lists would be good.
20:27:40 [pfps]
I'm happy with publishing "as is" (i.e. with the changes mentioned).
20:27:57 [TallTed]
+1 publish after today's changes are applied
20:28:06 [aryman]
+1 to publish
20:28:19 [Dimitris]
20:28:23 [Arnaud]
PROPOSED: Pending edits regarding issue-23 and issue-115, publish the updated SHACL draft
20:28:30 [pfps]
20:28:37 [hknublau]
20:29:10 [kcoyle]
20:29:11 [simonstey]
20:29:14 [aryman]
20:29:18 [ericP]
20:29:19 [TallTed]
20:29:22 [Dimitris]
20:29:26 [Labra]
20:29:38 [Arnaud]
RESOLVED: Pending edits regarding issue-23 and issue-115, publish the updated SHACL draft
20:30:01 [pfps]
test cases for next week?
20:30:51 [Arnaud]
trackbot, end meeting
20:30:51 [trackbot]
Zakim, list attendees
20:30:51 [Zakim]
As of this point the attendees have been Arnaud, kcoyle, simonstey, ericP, pfps, aryman, hknublau, labra, Dimitris, TallTed
20:30:59 [trackbot]
RRSAgent, please draft minutes
20:30:59 [RRSAgent]
I have made the request to generate trackbot
20:31:00 [trackbot]
RRSAgent, bye
20:31:00 [RRSAgent]
I see no action items