17:56:44 <RRSAgent> RRSAgent has joined #shapes
17:56:44 <RRSAgent> logging to http://www.w3.org/2016/06/16-shapes-irc
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> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.06.16
17:57:06 <Arnaud> chair: Arnaud
17:58:38 <kcoyle> kcoyle has joined #shapes
17:59:46 <Arnaud> present+
18:00:28 <simonstey> present+
18:00:56 <Dimitris> present+
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> present+
18:02:18 <hknublau> present+
18:04:19 <TallTed> present+
18:05:30 <ericP> scribenick: ericP
<ericP> topic: Admin
18:05:58 <ericP> PROPOSED: Approve minutes of the 9 June 2016 Telecon: http://www.w3.org/2016/06/09-shapes-minutes.html
18:06:41 <ericP> APPROVED: Approve minutes of the 9 June 2016 Telecon: http://www.w3.org/2016/06/09-shapes-minutes.html
18:07:41 <ericP> Next meeting: 2016.06.23
18:08:02 <ericP> topic: Disposal of Raised Issues
18:08:30 <ericP> ISSUE-168
18:08:30 <trackbot> ISSUE-168 -- How to constrain number of instances of a class in a graph -- raised
18:08:30 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/168
18:08:42 <ericP> Arnaud: is there a use case for issue-168?
18:08:53 <simonstey> +1
18:08:54 <ericP> kcoyle: not in the doc now
18:09:17 <TallTed> +1
18:09:39 <Arnaud> PROPOSED: Open ISSUE-168
18:09:43 <Dimitris> +1
18:09:47 <kcoyle> +1
18:09:49 <hknublau> +1
18:10:03 <pfps> +1
18:10:14 <Arnaud> RESOLVED: Open ISSUE-168
18:10:14 <ericP> +?
18:10:27 <simonstey> +1
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> topic: 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> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-22:_Treatment_of_recursive_shape_definitions
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> https://www.w3.org/2015/12/16-shapes-minutes.html#resolution04
18:15:45 <Dimitris> previous 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> q+
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> q+
18:18:41 <Arnaud> ack ericP
18:19:02 <ericP> -> http://shexspec.github.io/semantics/ ShEx semantics
18:20:16 <Dimitris> q+
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> q+
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> q+
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> +1
18:27:28 <simonstey> +0.5
18:27:28 <Dimitris> +1
18:27:29 <ericP> -.5
18:27:31 <kcoyle> +1
18:27:48 <pfps> 0
18:27:54 <TallTed> +0.5
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> topic: ISSUE-128
18:30:16 <trackbot> issue-128 -- sh:defaultValueType is rdfs:range -- closed
18:30:16 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/128
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> q+
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> q+
18:35:44 <Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0057.html
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> q+
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> 0
18:42:01 <simonstey> +0
18:42:08 <Dimitris> +0.5
18:42:14 <pfps> +1
18:42:34 <kcoyle> +.5
18:42:40 <TallTed> +1
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> +1
18:45:46 <TallTed> +0.5
18:45:46 <hknublau> (constraints and sh:Shapes)
18:45:54 <Dimitris> +1
18:46:05 <hknublau> 0.5
18:46:22 <Arnaud> s/RESOLVED/PROPOSED/
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> topic: ISSUE-41
18:46:49 <trackbot> issue-41 -- Using property paths to refer to values/types? -- open
18:46:49 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/41
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> q+
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> q+
18:54:32 <pfps> Why not sh:path IRI|list?
18:54:39 <Arnaud> ack ericP
18:55:31 <hknublau> q+
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> yes
18:59:28 <ericP> q+
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> q+
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> topic: ISSUE-139
19:05:33 <trackbot> issue-139 -- Can all constraint properties be applied in all scenarios? -- open
19:05:33 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/139
19:05:51 <hknublau> q+
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> q+
19:08:48 <pfps> Not.
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> q+
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> and NOT BOTH
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> q+
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> q+
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> q-
19:19:58 <pfps> q+
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> q+
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> q+
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> q+
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> q+
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, ericP, kcoyle, pano
19:33:39 <trackbot> RRSAgent, please draft minutes
19:33:39 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/16-shapes-minutes.html trackbot
19:33:40 <trackbot> RRSAgent, bye
19:33:40 <RRSAgent> I see no action items