IRC log of shapes on 2016-06-16

Timestamps are in UTC.

17:56:44 [RRSAgent]
RRSAgent has joined #shapes
17:56:44 [RRSAgent]
logging to
17:56:46 [trackbot]
RRSAgent, make logs rdf-data-shapes
17:56:46 [Zakim]
Zakim has joined #shapes
17:56:48 [trackbot]
Zakim, this will be SHAPES
17:56:48 [Zakim]
ok, trackbot
17:56:49 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
17:56:49 [trackbot]
Date: 16 June 2016
17:57:00 [Arnaud]
17:57:06 [Arnaud]
chair: Arnaud
17:58:38 [kcoyle]
kcoyle has joined #shapes
17:59:46 [Arnaud]
18:00:28 [simonstey]
18:00:56 [Dimitris]
18:01:18 [hknublau]
hknublau has joined #shapes
18:01:23 [pano]
Hi all, FYI, due to holidays I will most likely not be able to attend the next 2 calls.
18:01:32 [pfps]
pfps has joined #shapes
18:01:37 [pfps]
18:02:18 [hknublau]
18:04:19 [TallTed]
18:05:30 [ericP]
scribenick: ericP
18:05:58 [ericP]
PROPOSED: Approve minutes of the 9 June 2016 Telecon:
18:06:41 [ericP]
APPROVED: Approve minutes of the 9 June 2016 Telecon:
18:07:41 [ericP]
Next meeting: 2016.06.23
18:08:02 [ericP]
topic: Disposal of Raised Issues
18:08:30 [ericP]
18:08:30 [trackbot]
ISSUE-168 -- How to constrain number of instances of a class in a graph -- raised
18:08:30 [trackbot]
18:08:42 [ericP]
Arnaud: is there a use case for issue-168?
18:08:53 [simonstey]
18:08:54 [ericP]
kcoyle: not in the doc now
18:09:17 [TallTed]
18:09:39 [Arnaud]
18:09:43 [Dimitris]
18:09:47 [kcoyle]
18:09:49 [hknublau]
18:10:03 [pfps]
18:10:14 [Arnaud]
18:10:14 [ericP]
18:10:27 [simonstey]
18:12:03 [ericP]
Arnaud: does ShEx do this?
18:12:20 [pfps]
I fixed the pointer to the spec in the meeting agenda (sh:valueShape is now sh:shape and the section number has changed)
18:12:30 [ericP]
ericP: not as such. we're working on a UNIQUE constraint which would work for the stated use cases of exactly one
18:12:55 [ericP]
ISSUE-22: recursion
18:12:55 [trackbot]
Notes added to ISSUE-22 Treatment of recursive shape definitions.
18:13:15 [pfps]
Just reload the agenda - I fixed the reference
18:14:38 [ericP]
Dimitris: last time we decided that recursion is forbidden and shapes graph with a cycle is invalid
18:14:45 [Arnaud]
18:15:14 [ericP]
... we could take a conservative approach and close the issue on that, or we could say the it's valid but we don't say how recursion works
18:15:33 [Dimitris]
18:15:45 [Dimitris]
RESOLUTION: The starting point for recursion in SHACL is that shapes graphs with dependency loops are invalid, suitable limitations of this will be explored
18:16:11 [ericP]
Arnaud: iirc, we resolved saying "we're not doing recursion" but we left it open hoping someone would propose a solution to recursion
18:16:28 [ericP]
... arthur expressed interest but has left the WG
18:16:37 [hknublau]
18:16:42 [Arnaud]
ack hknublau
18:17:18 [ericP]
hknublau: we were waiting for arthur to come up with a proposal, no one else wanted to
18:17:33 [ericP]
... we were hoping for something from ShEx
18:17:43 [ericP]
... there's a page of use cases
18:18:11 [ericP]
... this week I ran into another use case in SHACL itself: path expressions which can recursively include other paths
18:18:37 [ericP]
18:18:41 [Arnaud]
ack ericP
18:19:02 [ericP]
-> ShEx semantics
18:20:16 [Dimitris]
18:20:21 [Arnaud]
ack Dimitris
18:20:29 [ericP]
ericP: it's not that hard; just follow Ёвка's rules on what makes a sound shapes graph
18:20:57 [hknublau]
18:21:07 [ericP]
Dimitris: because there is no time, we could say that it's not forbidden
18:21:50 [ericP]
Arnaud: last time we thought we could leave it to implementors
18:21:57 [Arnaud]
ack hknublau
18:22:11 [ericP]
hknublau: even if we forbid it, we'd have to do some work
18:22:20 [ericP]
... we'd have to define a recursive shape
18:22:33 [ericP]
... we also have the hasShape function which has some use cases
18:22:51 [TallTed]
"Effects of recursion (within shapes, path expressions, etc.) are undefined in SHACL 1."
18:23:16 [ericP]
... e.g. path expressions which are an RDF Collection
18:23:24 [ericP]
... this adds to the engine's work load
18:23:43 [ericP]
... it needs to do static analysis or it may crash
18:23:54 [ericP]
... we could say it's an invalid shapes graph
18:24:11 [ericP]
... that would allow people to compile to a single SPARQL query
18:24:26 [ericP]
... also allow implementations like mine which support recursion
18:24:39 [Dimitris]
18:24:58 [ericP]
Arnaud: we're not exactly silent on recursion
18:25:05 [Arnaud]
ack Dimitris
18:25:28 [ericP]
Dimitris: there's some mention of recursion in sh:shape and sh:hasShape
18:26:02 [ericP]
Arnaud: our current text isn't REC-ready "the WG will explore..."
18:26:16 [ericP]
... we can change the text to say it's implementation-dependent
18:26:48 [ericP]
... to be "silent", we'd have to remove that section, which would probably leave people wondering
18:27:06 [Arnaud]
PROPOSED: Close ISSUE-22, leaving recursion to implementations
18:27:11 [hknublau]
18:27:28 [simonstey]
18:27:28 [Dimitris]
18:27:29 [ericP]
18:27:31 [kcoyle]
18:27:48 [pfps]
18:27:54 [TallTed]
18:28:24 [pfps]
Does this mean that you, Eric, are willing to convert the ShEx solution to a SHACL solution?
18:29:16 [Arnaud]
RESOLVED: Close ISSUE-22, leaving recursion to implementations
18:29:51 [pfps]
Having an explicit gap is better than having an error in the spec (like in SPARQL)
18:30:16 [ericP]
18:30:16 [trackbot]
issue-128 -- sh:defaultValueType is rdfs:range -- closed
18:30:16 [trackbot]
18:30:41 [ericP]
Arnaud: technically closed, but Dimitris pointed out a problem with the earlier resolution
18:30:58 [ericP]
Dimitris: this problem came an editorial issue raised by peter
18:31:22 [ericP]
... specifically, "we don't allow inference and graphs are immutable"
18:31:33 [pfps]
I'm not sure that I was the one pointing out the "immutability" problem.
18:31:48 [ericP]
... i propose we remove sh:defaultValueType
18:31:50 [hknublau]
18:31:57 [Arnaud]
ack hknublau
18:32:14 [ericP]
hknublau: why do we explicitly have to tie those nodes?
18:32:39 [ericP]
... there's still a predicate which allows us to determine the type at run-time
18:32:53 [ericP]
Dimitris: how do we do that without inference?
18:33:16 [ericP]
hknublau: if the edge were sh:property, i'd just execute it as a sh:PropertyConstraint
18:33:47 [ericP]
Dimitris: we can remove it and meet the explicit type
18:34:13 [ericP]
hknublau: if we force the type to be used everywhere, we'd overload e.g. ORs
18:34:26 [ericP]
... it would be redundent where there's only one possibility
18:34:51 [ericP]
Arnaud: what if we alter the claim that the graph is immutable?
18:35:14 [ericP]
18:35:44 [Dimitris]
18:36:01 [Arnaud]
ack ericP
18:36:12 [ericP]
TallTed: Dimitris's email has an alternative proposal changing the requirement regarding graph immutability
18:36:17 [Dimitris]
I would prefer to remove sh:defaultValueType but would be ok with the other options as well
18:36:27 [ericP]
TallTed: if we change it, we have to be explicit about how it's mutable
18:37:20 [ericP]
Arnaud: Dimitris offered 3 proposals: (1) drop sh:defaultValueType, (2) change defn of sh:defaultValueType, (3) change the claim about the immutability
18:38:22 [Dimitris]
Peter, if we say something like property constraints are shacl instances of sh:PropertyConstraint or nodes linked with sh:property, would we be fine?
18:38:36 [pfps]
Problems arise if the shapes graph is also the data graph.
18:38:45 [ericP]
ericP: if you decide that schemas or data is mutable, you have to decide what happens when you validate data out there on the web
18:38:49 [hknublau]
18:38:55 [Arnaud]
ack hknublau
18:39:11 [ericP]
Arnaud: dropping it requires dropping accepted use cases, which were accepted sometimes not without pushback
18:39:56 [ericP]
hknublau: the use cases have changed; we were using it to discriminate between SPARQL constraint and node constraint
18:40:05 [ericP]
Arnaud: if we're not losing anything, let's kill it
18:40:37 [ericP]
hknublau: we'd have to write stuff; currently we change the semantics based on the type.
18:40:54 [ericP]
... we could infer based on whether there's an sh:property
18:41:10 [pfps]
It would be possible to say that constraints are those nodes in the shapes graph that are RDFS instances of sh:Constraint in the union of the shapes graph and the SHACL "ontology", which would include things like sh:property rdfs:range sh:<whatever>
18:41:19 [ericP]
Arnaud: do we need a proposal or should we agree on this and leave it up to [the editors] to implement?
18:41:33 [Arnaud]
PROPOSED: Change resolution of ISSUE-128, dropping sh:defautValueType
18:41:57 [hknublau]
18:42:01 [simonstey]
18:42:08 [Dimitris]
18:42:14 [pfps]
18:42:34 [kcoyle]
18:42:40 [TallTed]
18:42:48 [ericP]
Dimitris: in general, i agree; it may be the best of the three options
18:43:26 [ericP]
hknublau: i hope this doesn't make rdf:type triples mandatory
18:43:37 [ericP]
Arnaud: good point. this is what Dimitris didn't want
18:43:57 [pfps]
A property constraint in the the shapes graph is a node that is an RDFS instance of sh:PropertyConstraint in the graph that is the union of the shapes graph and the SHACL syntax graph.
18:44:56 [ericP]
s/this is what Dimitris didn't want/in Dimitris's email, he said we could no longer elide type triples/
18:45:16 [ericP]
Dimitris: pfps proposed wording to leave type triples optional
18:45:27 [Arnaud]
RESOLVED: Change resolution of ISSUE-128, dropping sh:defautValueType, without mandating the rdf:type triple on constraints
18:45:41 [pfps]
18:45:46 [TallTed]
18:45:46 [hknublau]
(constraints and sh:Shapes)
18:45:54 [Dimitris]
18:46:05 [hknublau]
18:46:22 [Arnaud]
18:46:29 [Arnaud]
RESOLVED: Change resolution of ISSUE-128, dropping sh:defautValueType, without mandating the rdf:type triple on constraints
18:46:49 [ericP]
18:46:49 [trackbot]
issue-41 -- Using property paths to refer to values/types? -- open
18:46:49 [trackbot]
18:47:15 [ericP]
Arnaud: we agreed to add property paths and holger got to work on it
18:47:36 [ericP]
hknublau: there were two changes in the first round:
18:48:22 [ericP]
... .. result format no longer makes sense -- it was oriented towards single triples rather than path expressions. propose just (focus node, path, value)
18:48:33 [pfps]
The change from fn,s,prop,o to fn,path,val is a good one - it is more uniform and also makes implementation easier
18:49:01 [ericP]
... .. instead of differnt props linking, we could have just one property, sh:validator, which points to a Validator object
18:49:26 [ericP]
... it seems to me that single value data is sufficient which would simplify the data model
18:49:59 [ericP]
... vendor's can extend their own extensions to sneak in optimizations specific to their platform
18:50:36 [Dimitris]
18:50:50 [Arnaud]
ack Dimitris
18:51:18 [simonstey]
I second pfps' comment
18:51:18 [ericP]
Dimitris: i had an offline discussion with hknublau about syntax about the metamodel and how it addresses path expressions
18:51:34 [ericP]
... we wanted to simplify the user syntax and then fix the metamodel
18:51:58 [ericP]
hknublau: are you referring to replacing inverseProperty with a path?
18:52:30 [ericP]
... the language was originally designed to have paths, there's overlap
18:52:40 [ericP]
... this implies that there are now two syntaxes for the same thing
18:53:03 [ericP]
... we could get rid of inverse property -- the value isn't that great and we can leave it to a path expression
18:53:37 [ericP]
... the specific syntax we'd favor is:...
18:53:40 [hknublau]
ex:MyShape sh:property [ sh:predicate|sh:path ... ]
18:54:14 [ericP]
hknublau: this would eliminate a lot of redundancy.
18:54:29 [ericP]
... we could say that a predicate is an IRI and a path is a blank node
18:54:31 [ericP]
18:54:32 [pfps]
Why not sh:path IRI|list?
18:54:39 [Arnaud]
ack ericP
18:55:31 [hknublau]
18:55:41 [Arnaud]
ack hknublau
18:55:52 [Dimitris]
ericP, I think you got it wrong, sh:property would have either sh:predicate as IRI or sh:path as rdf:List
18:56:37 [ericP]
ericP: i'm reluctant to have the RDF syntax (bnode vs. IRI) affect the interpretation. prefer not caring about bnode vs. IRI for paths with some extra discriminators for paths
18:56:54 [ericP]
pfps: i think having sh:predictate vs. sh:path might be better
18:57:24 [ericP]
... i agree that IRIs vs. bnodes is the obvious approach but agree with ericP that it's fragile
18:57:53 [simonstey]
not me
18:58:22 [simonstey]
18:59:28 [ericP]
18:59:54 [Arnaud]
ack ericP
19:01:08 [pfps]
No recursion here, I think. Instead this is a way of elminating many needs for recursion.
19:01:11 [pfps]
19:01:32 [Arnaud]
ack pfps
19:01:41 [ericP]
ericP: we have to think about recursion, e.g. ^foaf:knows/foaf:knows
19:02:08 [ericP]
pfps: recursion isn't coming back to the same node, it's coming back to the same shape
19:05:08 [ericP]
... there are problemantic recursive graphs, but don't show up with finite graphs
19:05:22 [ericP]
... (i.e. not graphs which abide by the RDF semantics)
19:05:33 [ericP]
19:05:33 [trackbot]
issue-139 -- Can all constraint properties be applied in all scenarios? -- open
19:05:33 [trackbot]
19:05:51 [hknublau]
19:06:02 [Arnaud]
ack hknublau
19:06:23 [ericP]
hknublau: i believe there are 3 topics under this issue:
19:06:37 [ericP]
... .. boiler plate in queries
19:06:51 [ericP]
... .. whether all constraints can be applied everwhere
19:07:16 [ericP]
... .. .. whether tools can have hints about what's allowed
19:07:47 [ericP]
... .. change in the meaning of node constraint from a single set to a set of nodes in-scope
19:08:41 [ericP]
... pfps pointed out that most or all of the core components can be expressed with a boilerplate macro inserted into the queries
19:08:46 [Dimitris]
19:08:48 [pfps]
19:08:56 [ericP]
Arnaud: i thought i saw convergence
19:09:18 [ericP]
hknublau: pfps always wants the boiler plate in the start of the query
19:09:26 [pfps]
19:09:27 [Arnaud]
ack Dimitris
19:09:34 [ericP]
... also wants to inject it into the middle, which seems better to me
19:10:28 [ericP]
Dimitris: started this because of nodeConstaaint, inverseNodeConstraint, propertyConstraint, invPropertyconstraint, pathConstraint
19:10:50 [Arnaud]
ack pfps
19:10:53 [ericP]
... simplifying this could make the macro very short and reduce need for the macro
19:11:08 [ericP]
pfps: i guess the boilerplate solution comes from me
19:11:19 [ericP]
... my impl only uses macro expansion
19:11:33 [ericP]
... but now we have both macro and pre-binding
19:11:48 [ericP]
... if we're going to use macros we shouldn't also have pre-binding
19:11:59 [ericP]
... that's one issue with the current proposal
19:12:57 [ericP]
... on the other side, it's possible to implement all core components without macro expansion as long as you have a fixed version of pre-binding
19:13:09 [ericP]
... there's a YUGE problem with pre-binding
19:14:01 [ericP]
... i was looking back at old SPARQL discussions: there's a problem with substitution in pre-binding
19:14:26 [ericP]
... in some sense, if we're going to make this work, we have to roll our own:
19:14:36 [ericP]
... .. either pre-binding
19:14:52 [ericP]
... .. or @@2
19:15:09 [pfps]
The solution should be EITHER macro expansion or a version of pre-binding defined as initial solution sequences
19:15:26 [pfps]
19:15:35 [ericP]
s/either pre-binding/macro expansion/
19:15:53 [ericP]
s/or @@2/a version of pre-binding defined as initial solution sequences/
19:16:17 [Dimitris]
I agree to use one option
19:16:30 [ericP]
hknublau: not sure why this is related here. (may be, but i don't see it yet)
19:16:53 [Dimitris]
19:16:59 [Arnaud]
ack Dimitris
19:17:00 [ericP]
... i'm happy with a better definition which covers a similar set of use cases
19:17:06 [ericP]
... prob i see is bnodes
19:17:25 [ericP]
Dimitris: we need to pass bnodes to the sh:hasShape function
19:17:26 [ericP]
19:17:59 [ericP]
hknublau: if someone wants to validate a specif bnode and not the whole graph, how can you pass it in?
19:18:06 [pfps]
Aah, you are saying that macro expansion doesn't work when the focus node is a blank node. Yeah, that's a problem.
19:18:09 [ericP]
Dimitris: you can't
19:18:36 [ericP]
... the purposes of a bnode is that you can't address it from outside your database. you can't solve this problem
19:19:01 [ericP]
hknublau: is most cases, [you can address bnodes]
19:19:20 [pfps]
OK, macro expansion into the source is not adequate, you have to expand in the algebra where blank nodes are permissable.
19:19:23 [Arnaud]
ack ericP
19:19:25 [ericP]
Dimitris: *some* implementations [support told nodes]
19:19:30 [ericP]
19:19:58 [pfps]
19:20:06 [Arnaud]
ack pfps
19:20:19 [ericP]
Arnaud: if macro expansion doesn't work for bnodes, that leaves pre-bindings
19:20:37 [ericP]
pfps: macro expansion directly into the SPARQL source is problematic
19:20:40 [hknublau]
19:20:55 [ericP]
... could do macro expansion into the SPARQL algebra because that allows bnodes
19:21:45 [ericP]
... but i believe that initial VALUES solution is what we need
19:22:07 [ericP]
... SPARQL algebra name is "solution sequence"
19:22:30 [ericP]
... you may lose some power and certain things become more difficult, but i don't view that as a bad thing
19:22:34 [Arnaud]
ack hknublau
19:22:59 [ericP]
hknublau: as pfps said, there is the option to do that macro expansion on the data structure level
19:23:04 [ericP]
... that's what i always wanted
19:23:23 [ericP]
... start with a SPARQL string; this gets compile into an abstract syntax.
19:23:53 [ericP]
... at that stage, the macro expansion occurs, so you get to utter bnodes
19:24:11 [pfps]
19:24:27 [Arnaud]
ack pfps
19:24:50 [ericP]
pfps: it appears that are irreconcilable value differences (affecting us for quite some time)
19:25:03 [Dimitris]
19:25:03 [ericP]
... i don't see those changing so i don't know if progress is possible
19:25:15 [Arnaud]
ack Dimitris
19:25:40 [ericP]
Dimitris: what hknublau proposes is substitution but done in a special way which can inject bnodes?
19:26:00 [ericP]
hknublau: in Jena, it's called "syntax transforms"
19:26:18 [ericP]
Dimitris: this could be done with string substituion?
19:26:46 [ericP]
hknublau: this gets more complex, e.g. substituting into a BIND(X AS ?y)
19:27:05 [ericP]
... the spec tries to be general without prescribing how it's supposed to be implemented
19:27:07 [hknublau]
(e.g. bound(?preBoundVar) would produce syntax error
19:27:25 [pfps]
There are multiple problems with syntax transformations - all related to the use of variable names as variables as opposed to the use of variable names as their value.
19:27:56 [ericP]
FILTER(?o = "ab ?o ")
19:28:05 [pfps]
Unfortunately SPARQL has many places where the fact that a bit of syntax is a variable is important, not just in BIND and SELECT but also in MINUS.
19:28:30 [pfps]
19:29:17 [Arnaud]
ack pfps
19:29:29 [ericP]
pfps: there's quite a lot of discussion on "substitute" which is part of the SPARQL defn which has a description which is open to multiple interpretations
19:33:31 [Arnaud]
trackbot, end meeting
19:33:31 [trackbot]
Zakim, list attendees
19:33:31 [Zakim]
As of this point the attendees have been Arnaud, simonstey, Dimitris, pfps, hknublau, TallTed, ?, .5
19:33:39 [trackbot]
RRSAgent, please draft minutes
19:33:39 [RRSAgent]
I have made the request to generate trackbot
19:33:40 [trackbot]
RRSAgent, bye
19:33:40 [RRSAgent]
I see no action items