13:48:51 RRSAgent has joined #shapes 13:48:51 logging to http://www.w3.org/2015/12/15-shapes-irc 13:48:53 RRSAgent, make logs rdf-data-shapes 13:48:53 Zakim has joined #shapes 13:48:55 Zakim, this will be SHAPES 13:48:55 I do not see a conference matching that name scheduled within the next hour, trackbot 13:48:56 Meeting: RDF Data Shapes Working Group Teleconference 13:48:56 Date: 15 December 2015 13:49:04 hsolbrig has joined #shapes 13:50:02 Tried the webex link in the meeting announcement, but it says it is waiting for a host to arrive 13:50:14 yes 13:50:24 it looks like Eric screwed up the reservation 13:50:47 for me it says "When it's time, join your meeting here. " and the button is disabled 13:51:06 yeah.. he set it to PM instead of AM 13:51:20 I get "meeting not started" 13:51:57 Meeting has not yet started The meeting starts at 8:30 pm, Eastern Standard Time (New York, GMT-05:00). Please try joining this meeting again at that time. 13:51:58 aryman has joined #shapes 13:52:14 Tried the phone number w/ no better success 13:52:34 Yup - 8:30 PM. oops 13:52:35 webex says meeting starts at 8:30pm 13:52:55 if Eric shows up we'll have him fix it 13:53:09 otherwise we'll use my IBM teleconf number 13:54:10 see, this is why I set the start time 15mn before the actual meeting :) 13:54:38 hehe 13:56:27 ok, webex is started 13:58:53 mit webex? we should try again? 13:58:58 yep 13:59:34 present+ 13:59:34 present+ aryman 13:59:41 present+ ericP 13:59:51 present+ hsolbrig 13:59:57 present+ 13:59:57 present+ 14:00:05 present+ 14:00:32 pfps has joined #shapes 14:00:42 present+ 14:01:47 greetings? 14:05:26 agenda: https://www.w3.org/2014/data-shapes/wiki/F2F5#Agenda 14:05:30 chair: Arnaud 14:05:46 scribe: ericP 14:06:07 Arnaud: 5th "F2F" meeting 14:06:20 no holger, no jose 14:06:41 "I will be offline for the next two weeks; back just in time for the F2F. Regards Holger" 14:07:16 ... i asked folks to list the top issues upon which we should focus the meetinng 14:07:35 ... we've been tackling smaller issues in calls 14:07:50 ... we'll use the F2F to tackle big issues 14:08:09 TallTed has joined #shapes 14:08:25 ... i spread these issues across the three days in the agenda 14:08:55 ... late change: moved the discussion of shex and the test suite to the last day 14:10:30 ... we'll clarify the Thu agenda over the next couple days 14:11:22 .. main items: the spec itself, UC&R, shex/user-friendly syntax, testing 14:11:30 ... main items: the spec itself, UC&R, shex/user-friendly syntax, testing 14:11:41 ... we'll need tests to go to CR 14:12:36 I know that issue 23 is very important for him 14:12:51 topic: ISSUE-23 -- Shapes as classes 14:12:52 Issue-23 -- Shapes as classes -- open 14:12:52 http://www.w3.org/2014/data-shapes/track/issues/23 14:13:24 Arnaud: some folks, particularly TQ, want to use SHACL as a modeling language 14:13:46 ... the spec has evolved quite a lot from overt shapes-as-class 14:15:11 ... holger still wants to be able to use the type arc to connect classes and shapes 14:15:40 https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Nov/0168.html 14:15:46 ... we can either say "hell no" and let TQ file an objection, or accept the latest proposal for shapeClass 14:16:30 q+ 14:16:33 There are many problems with using SHACL as a modelling language. SHACL uses the RDFS class language but gives it a different meaning. This is regrettable for validation, but not catastrophic. If SHACL is used as a modelling language and uses the RDFS vocabulary then its meaning for RDFS modelling language that it uses must align with the RDFS meaning. 14:16:34 q+ 14:16:35 ack Dimitris 14:16:50 Dimitris: there was a recent update 14:17:07 https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-23:_Shapes_as_Classes 14:17:08 ... we remove all the meta-classes 14:17:14 ... keep the same syntax 14:18:00 ... shapeClass is no longer a meta-class 14:18:05 ... rename to classShape 14:18:21 ... implies that it's a graph, but we don't say it 14:18:36 what does this buy us? 14:18:37 ... it's only a shortcut now -- doesn't do any modeling 14:18:56 q+ 14:19:53 ack pfps 14:20:46 pfps: if we do this and look at a SHACL file that uses this facility, it still looks the same: 14:21:01 ... ... :Joe a :Person . 14:21:19 ... Joe will still be an instance of a class and that class will have constraints on it. 14:21:45 ... regardless of whether SHACL's turtle file says it's a class, it's a class 14:22:12 ... if we're going to use SHACL for class-based modeling, the RDFS is the game in town. 14:22:26 ack aryman 14:22:26 q+ 14:22:27 ... we should not be splitting the class-based modeling facilities provided by W3C 14:22:30 q+ 14:22:34 +1 for not changing meaning of class as per peter 14:22:49 aryman: this proposal does eliminate the ShaleClass meta-class. 14:22:58 So, in short, SHACL should not be providing a version of class-based modelling that is incompatible with RDFS 14:23:19 ... i don't think there's debate over whether scopeClass is problematic; we want to say "apply a shape to all instances of a class" 14:24:05 ... this is syntactic sugar for any node which is both a shape and a class, implying that it's a shape 14:24:20 ... we can't prevent folks from writing this. 14:24:22 q+ 14:24:42 ... the proposal says "if we find this construct, draw the right conclusion" 14:24:57 My point is that if we find a class as a shape then SHACL should really be doing the right thing, which includes applying the RDFS semantics to it. 14:25:23 ... i'm conditionally ok with this if we don't include examples of this in our spec. 14:25:44 Arnaud: we could have a section talking about the caveats 14:26:11 ... e.g. associating a class with a shape blocks users from assigning a different shape 14:26:16 I think that the point of making a class a shape is precisely to block other kinds of shapes being applied to the class. 14:26:38 +1 do arthur's comment on locality 14:26:46 aryman: in holger's context, they change the definition of a class depending on context. 14:26:53 ... i'm interested in the downside 14:27:05 ack hsolbrig 14:27:11 ... i object on philosophical grounds, but what practically breaks? 14:27:25 hsolbrig: aryman clarified a lot of my questions. 14:28:24 hsolorig's audio is very choppy for me 14:28:30 same here 14:28:46 ... [lots of ominous sound effects] 14:28:48 s/hsolorig/hsolbrig/ 14:29:48 If you are using a reasoner, Mary can't simultaneously be a person and a shape -- have parents, hobbies and literals 14:30:05 ack ericP 14:30:06 @pfps other shapes can be applied to a class by using sh:scopeClass 14:30:09 So, as long as it is clear that Person and PersonShape can be linked as separate things 14:30:27 ericP: problem is it becomes more complex 14:30:38 I can't object to making :Person both a thing with parents, friends, and triples... 14:31:01 As long as it is obvious in the spec that you don't have to (and, hopefully, it isn't recommended) 14:31:06 ericP: ... to recognize a shape 14:31:17 ack pfps 14:31:25 @ericP so that doesn't actually break anything, just makes implementation harder 14:31:36 pfps: re what breaks in SHACL, nothing breaks; you can define these things. 14:31:59 q+ 14:31:59 ... you end up asking questions like "when is John an instance of a shape?" 14:32:19 ack aryman 14:32:38 John, upon loss of his job was reduced to a set of triples... 14:32:43 ... so we end up with a new way to assert membership which doens't leverage RDFS. i think that's a bad thing. 14:33:05 aryman: we can't prevent folks from creating nodes that are shapes and classes. 14:33:24 ... we can say we don't want this implicit inference. 14:33:33 SHACL could actually say "If a data graph has a shape that is also a class then an error results" 14:33:36 q+ 14:33:54 Is that your opinion, John, or is it just your shape speaking? 14:33:57 ... how much of a burden is it to add the scopeClass triple explicitly 14:34:36 ... peter and ericP are both reluctant. 14:34:58 ... it does require inference; it raises the question of how much inference to do 14:35:20 ... then we may decide we don't wnat to go half-way, then we use all of RDFS 14:35:47 ... holger's tool can have a mode that adds the scopeClass automagically 14:36:17 ack pfps 14:36:45 Arnaud: holger has said that he won't accept having an extra triple when a node is a shape and a class 14:37:21 pfps: if you feel like shapes and classes are different, we should add "any node which is both a shape and a class is an error" 14:38:06 aryman: make that a counter-proposal 14:39:17 pfps: i don't advocate throwing an error when classes are shapes, but i've heard several people in this group say it's wrong. 14:39:27 ... those folks should stand by their guns. 14:40:04 My goal is to allow the approach I need, not disallow any opposing views 14:40:50 The latest proposal was never announced, so I hadn't looked at it. 14:41:27 q+ 14:41:32 ack pfps 14:41:59 pfps: i like aryman's proposal. (not on our list, is it?) 14:42:13 that's the status quo right? 14:42:27 Which was what I was trying to advocate through the phone noise 14:42:35 ... that we don't forbid it, if you want to use it, you add the scopeClass triple yourself, and we don't have an example 14:43:12 Arthur's proposal as I take it is scopes can be classes, if you want to have them work then you add the scopeClass triple, and the documents don't have any shapes that are classes 14:43:16 simonstey: proposal B is to have a sentence saying that you can do it 14:43:17 "The scopeClass triple" being :person sh:scopeClass :person? 14:43:30 correct 14:44:30 I think Arthur's proposal is very sensible. Were my microphone working I would say as much 14:44:50 aryman: PROPOSAL: eliminate ShapeClass; do not disallow shape/class nodes; require explicit scopeClass; say "you can do it if you want; we won't throw an error." 14:45:55 Arnaud: in the latest proposal, Dimitris, you rename ShapeClass to ClassShape. what does that change? 14:47:30 +1 to Dimitris's comments - as soon as SHACL uses RDFS stuff for modelling, even for its own modelling, then it should be using the RDFS semantics 14:47:45 Dimitris: proposal D: whenever you have foaf:Person a owl:Class, shacl:Shape, you have to make the connection. 14:48:31 +1 to peter's +1 of Dimitris proposal 14:50:09 yes, that's right 14:50:42 How does proposal D differ with Arthur's proposal? 14:51:22 Arnaud: so in proposal D, scopeClass is implicit 14:51:36 "you have to make the connection == foaf:Person sh:scopeClass foaf:Person, no? 14:51:42 simonstey: i don't see the compromise 14:51:56 ... everything that was a ShapeClass is now a ClassShape. 14:52:30 Dimitris: if foaf:Person is a ClassShape, that implies foaf:Person sh:scopeClass foaf:Person . 14:53:23 simonstey: so it's B but without ShapeClass 14:56:29 Arnaud: either there is some sort of inferencing and Holger is happy, or it's explicit and he'll object. 14:57:13 I'm happy not inferring scopeclass 14:57:37 I'm happy not inferring scopeClass 14:57:49 I'm happy not inferring scopeClass 14:58:04 holger could live with (d) 14:58:38 PROPOSAL d: A variation of the existing definition in the spec with the removal of the triple "sh:ShapeClass rdfs:subClassOf rdfs:Class". This means that sh:ShapeClass is no longer a metaclass and the definition of "ex:MyShapeAndClass a rdfs:Class" is not of interest in SHACL. The SHACL engine will assume that the definition is defined "somewhere", not necessarily in the current shapes graph. To better reflect this behavior, sh:ShapesClass should be r[CUT] 14:58:48 To better reflect this behavior, sh:ShapesClass should be renamed to sh:ClassShape 14:59:20 ericP: What's the cost of writing scopeClass? 14:59:48 aryman: agree, expecially if you're using tools to create shapes and classes 15:04:26 ... i think holger makes the case for scopeClass being inferred 15:04:28 STRAWPOLL: Close ISSUE-23, don't have sh:ShapeClass, require explicit scopeClass 15:04:38 +1 15:04:42 +1 15:04:45 +1 15:04:48 +1 15:05:06 +1 15:05:16 +0.5 15:05:21 @Arnaud your audio cut out for 20 seconds - pls repeat 15:05:57 +1 15:06:09 Arnaud: if the whole WG agrees, i'll make the case that we should close with no inferencing of scopeClass 15:07:04 ... we'll give holger a last chance to make his case but i think the direction of the WG is clear 15:07:33 aryman: we should also be clear that we're not going to have examples that are both shapes and classes. 15:08:54 http://w3c.github.io/data-shapes/shacl/#scopeClass 15:09:01 simonstey: ShapeClass only shows up in 2.1.2 15:09:21 Arnaud: holger said it would impact the turtle file 'cause he uses it a lot. 15:09:45 aryman: i'm working on a cleaned up version of the vocab, perhaps showable tomorrow 15:10:19 RECESS! 15:10:22 (20 mins) 15:15:22 aryman, you're not on mute 15:15:44 am now 15:16:24 aryman, you don't have holger's phone #, do you? 15:21:18 we used Skype 15:21:34 let me check my email for another phone number 15:22:20 yeah, he's actually on skype but I tried to call and it didn't work 15:23:57 I guess you are automatically online on skype if you have it on your phone 15:24:52 yeah, it's not very reliable 15:31:45 yes, back 15:33:24 issue-73 15:33:24 issue-73 -- how do recursion errors from sh:hasShape interact with SPARQL -- open 15:33:24 http://www.w3.org/2014/data-shapes/track/issues/73 15:33:35 issue-93 15:33:35 issue-93 -- SHACL engine vs. SHACL instance requirements -- open 15:33:35 http://www.w3.org/2014/data-shapes/track/issues/93 15:33:52 topic: Implementation vs specification 15:34:18 pfps: i was expecting holger to say this was done 15:34:58 ... the last time i looked that spec, not long ago, there were a bunch of SPARQL definitions in the spec. 15:35:17 ... they have things that look like "bind sh:hasShape ... 4th arg" 15:35:35 ... this has morphed into how the spec handles recursion errors 15:35:47 ... there's a general statement that "if you get in a loop, it's an error" 15:36:38 the SPARQL DEFINITION sections in the spec (3.1.12, e.g.) have a particular implementation of recursion error, which I think are all messed up 15:37:18 this is just one example of places where there have been comments that implementation is driving or contradicting the spec 15:38:01 q+ 15:38:10 Arnaud: is there a separation recursion, error handling, spec vs. implementation? 15:38:19 ... how can we address these one by one? 15:38:25 holger replied to peter's concerns regarding 73 in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0052.html 15:38:44 pfps: the big question is "what do you want the spec for SHACL to be?" 15:38:48 ... .. prose? 15:38:54 ack aryman 15:38:54 ... .. formal construct? 15:38:59 ... .. SPARQL? 15:39:08 aryman: "yes" 15:39:16 ... [apparently to all] 15:39:21 ... we need prose 15:39:36 ... we need formality if we want someone other than Holger to look at it 15:39:46 ... and we agreed to illustrate with SPARQL 15:40:06 ... we're going beyond this with magic functions which are part of holger's implementation. 15:40:24 ... he's tried to describe what they do in psuedo-code 15:40:29 ... but they're too detailed. 15:40:41 ... we need something that folks can implement without reading all the code 15:41:16 ... SPARQL is a nice functional programming language, but we need to introduce more constructs 15:41:30 ... e.g. detecting a loop, is there a history of the nodes we've hit? 15:41:34 ... there's missing information. 15:41:54 ... i think it's fine to have a precise prose description to give folks the gist. 15:42:20 ... but i think we need a more formal and precise spec (more precise than most folks would want to read) 15:42:32 ... the only objection i've heard is that there's fear they'll get out of sync 15:42:45 ... most WGs manage to keep their docs in sync 15:42:58 ... most readers will want to use SHACL 15:43:06 ... a smaller set will want to implement. 15:43:19 ... we need to address both audiences 15:43:32 Arnaud: most WGs manage multiple docs. 15:44:19 I don't remember any other dates for this meeting 15:44:25 ... i've seen two or three docs from some WGs 15:48:31 ... TQ had implemented a generic extension mechanism and implemented SHACL on top of it. 15:49:20 ... they've historically been afraid we'd break this. 15:49:40 ... ... by separating the parts 15:50:26 aryman: the recursion has access to special constructs 15:50:36 ... why don't we have semantics specs? 15:51:31 Arnaud: if fear this is getting us back to the old discussion of a semantics and an abstract syntax doc 15:51:44 ... we've agreed to use SPARQL where possible 15:52:18 aryman: we agreed that SPARQL can't cover everything; there's a higher-level control structure 15:52:33 ... there's no reason not to have semantics spec 15:52:50 ... all the other RDF specs have a semantics doc 15:52:52 +1 15:53:22 none of whom are here 15:53:48 Arnaud: if jose were here, he'd support 15:54:02 ericP: or harold or iovka 15:54:23 pfps: i'm now conflicted as to whether this is a good idea 15:54:41 ... i did volunteer to work on the semantics but more on a SPARQL translation 15:54:48 ... we have a tough target to hit. 15:55:20 ... a number of pieces of SHACL have been developed with little regard for semantic cleanliness 15:56:01 Arnaud: my q may be redundant: 15:56:28 ... can we create a semantics doc that won't conflict with the SPARQL defn 15:56:52 pfps: sure, a lot will be non-controversial 15:57:00 q+ 15:57:08 ... down side, we need to make surue theyre' the same 15:57:26 ack aryman 15:57:35 scribe: kcoyle 15:58:05 aryman: issue is how do you arrive at a clear spec? ambiguities will come to light 15:58:18 ... process of writing formal spec will complement informal spec 15:58:39 ... which one is right? some spec languages are executable - Koch? system 15:59:05 ... could provide running code; we could see the consequence of our formal definitions 15:59:27 Coq 15:59:28 ... if you only have one there is no check 15:59:37 s/Koch/Coq 16:00:03 arn 16:00:22 Arnaud: what w3c does with translations; one always wins 16:00:58 aryman: it's fine to have prose version be normative if it is precise 16:01:15 ... mitigate risk with test suite 16:01:51 Arnaud: who will be the editor? 16:02:08 aryman: I'd rather do that than work on the informal spec (sounds like a volunteer) 16:02:15 +1 16:02:30 Arnaud: Should we go with this? 16:03:19 +1 16:03:25 PROPOSED: Arthur to draft a semantics doc for the WG to consider, that would complement the current SHACL spec 16:03:34 +1 16:03:39 +1 16:03:43 +1 16:03:48 +1 16:04:32 ericP: +1 16:04:42 +1 16:04:44 RESOLVED: Arthur to draft a semantics doc for the WG to consider, that would complement the current SHACL spec 16:04:58 ACTION: aryman to draft a semantics doc for the WG to consider, that would complement the current SHACL spec 16:04:58 Created ACTION-32 - Draft a semantics doc for the wg to consider, that would complement the current shacl spec [on Arthur Ryman - due 2015-12-22]. 16:05:32 q+ 16:05:39 Arnaud: back to general issue of specification vs implementation... 16:06:06 aryman: the issue of sparql binding - when you write an extention in sparql, what is the context it runs in? 16:06:23 ack pfps 16:06:25 ... there could be other bindings, e.g. javascript 16:07:15 pfps: there's an issue with extension mechanisms, but if formal spec is done right then it is a target for the implement, then implementaiton has no normative force 16:07:29 ... and sparql expansions become simply part of an implementation - they are no longer definitional 16:08:00 Arnaud: holger wsa interested in javascript extensions. 16:08:07 Arnaud: what Holger has said is the sparql would be foundational layer that is a built-in extension that everyone would support 16:08:12 ... although they could be others 16:08:17 q+ 16:08:19 s/they/there 16:08:33 ... how is this different? 16:08:41 ack pfps 16:09:13 pfps: not clear ont he question but... right now sparql expansion is definitional, so sparql has a privileged position 16:09:35 ... take that away, and the two definitional bits are the informal and the non-sparql formal definition 16:10:13 ... but because what is there is sparql++ we can't use it definitionally 16:10:52 using external functions makes it very hard to determine just what the meaning of SHACL is from the SPARQL expansions/definitions 16:10:56 ericp i can take it from now 16:11:44 q+ 16:11:47 aryman: there are some things we are using in sparql that mean we have to rely on the informal spec 16:11:57 ... can't say that sparql trumps the formal 16:12:22 ... but if we have a pure sparql definition, then there's already a formal spec, so that's definitional 16:12:44 q+ 16:12:45 the problem with using the SPARQL expansions is that many constructs use extension functions, so understanding much of SHACL through the SPARQL expansions requires these extension functions 16:12:49 ack Dimitris 16:13:31 Dimitris: I'm in favor of pure sparql, but part of spec that is not in pure sparql needs more definition; the part that can be expressed in sparql should be 16:13:43 ack simonstey 16:14:26 simonstey: our idea was that we didn't want to reinvent the wheel; we use sparql when sparql is sufficient to express the semantics; 16:14:57 ... when that is not possible, we need other formal semantics; this should not be controversial 16:15:44 Arnaud: summary, the use of sparql falls apart as soon as we use extensions 16:15:45 q+ 16:15:50 ack ericP 16:16:01 ericP: there is a cost to switching formalisms 16:16:36 ... that's an editorial decision in re what needs to be communicated to readers 16:17:23 q+ 16:17:38 ack pfps 16:18:00 pfps: I was unaware that this was about presentation; i thought it was about specification 16:18:24 ... we may decide that the formal spec is easier for shacl developers to read, and therefore we put that in the primer 16:18:36 ... but that's different form saying what the spec is 16:18:38 s/form/from 16:19:38 Arnaud: back to binding 16:19:45 q+ 16:20:11 aryman: editorially, binding issue needs to be separate out, either section or sep spec 16:20:34 ack pfps 16:21:12 pfps: where we put sparql extension is thorny issue; it could stay where it is 16:21:29 ... don't see what it needs a separate doc 16:22:38 q+ 16:22:43 aryman: the reason for separation is if people can agree on some things but not others; should disagreements hold up the whole spec? 16:22:50 ack pfps 16:23:10 pfps: there's no problem with publishing working drafts where different parts of the doc are in different stages of completion 16:23:48 ... yet it is polite to say so in the document (clearly), so I don't see arthur's problem 16:24:06 Arnaud: I agree with Peter on status of document and sections 16:24:36 q+ 16:24:41 ack pfps 16:24:45 aryman: but that implies that shacl isn't ocmplete unless we have defined sparql binding 16:25:03 pfps: that conflates issues: one could argue that the core of shacl is a good validation language 16:25:30 hknublau has joined #shapes 16:25:35 ... and will meet many use cases; but we could say that a shacl implementation could just be the core 16:26:05 ... or we could say that any implementation must have at least one extension language 16:26:40 q+ 16:26:58 aryman has joined #shapes 16:29:30 q- 16:29:43 ack hknublau 16:31:06 Arnaud: agreement for aryman to do semantics document; does this address issue of implementation vs specification 16:31:16 ericP: Yes, addresses issue 16:31:40 pfps: Yes, an independent formal spec that provides something to test implementation against 16:32:18 break for 30 minutes 16:32:19 RRSAgent, draft minutes 16:32:19 I have made the request to generate http://www.w3.org/2015/12/15-shapes-minutes.html Arnaud 16:32:47 So we are breaking 1/2 hour earlier, right? 16:34:02 Break now 16:59:21 Break over? 16:59:50 I did that already :) 17:02:46 kcoyle has joined #shapes 17:04:43 I can scribe for this session 17:04:49 scribe: pfps 17:05:04 arnaud: status of UCR document 17:05:16 arnaud: there is an updated editors' draft 17:05:30 q+ 17:05:33 arnaud: I remember that there was an intent to work on the document and then publish 17:05:43 ack simonstey 17:06:05 simon: Karen started the googledocs document about coverage of requirements 17:06:18 simon: the next step would have been to integrate this into the UCR document 17:06:21 http://w3c.github.io/data-shapes/data-shapes-ucr/under%20construction/indextabs.html#r1-higher-level-language 17:07:34 simon: I integrated this (and more) into the UCR document as Section 4 17:08:01 simon: more editorial work is needed 17:08:14 arnaud: this is about incorporating the googledocs document 17:08:48 simon: right, right now it is stated directly 17:09:07 karen: I'm fine with the current setup, and can finish it off this way 17:09:24 arnaud: this appears to be under the editors' control 17:09:52 simon: I'll set things up and karen will finish the editing 17:09:54 looks good to me 17:10:01 arnaud: this looks good 17:10:12 arnaud: let us know when the document is ready for revie 17:10:41 karen: it's mostly boring work 17:10:59 arnaud: thanks 17:11:11 karen: I need to do the work before I forget about it 17:11:28 Topic: Meta model 17:11:44 arnaud: There have been questions concerning the meta model 17:11:52 arnaud: there are two specific issues 17:11:57 ISSUE-78 17:11:57 ISSUE-78 -- Should SHACL support marking classes as abstract -- open 17:11:57 http://www.w3.org/2014/data-shapes/track/issues/78 17:12:02 ISSUE-95 17:12:02 ISSUE-95 -- Proposed simplification and clean up of template mechanism -- open 17:12:02 http://www.w3.org/2014/data-shapes/track/issues/95 17:12:18 arnaud: we should be arguing over general directions instead of specific details 17:12:37 q+ 17:13:09 ack aryman 17:13:57 arthur: I had some conversations with Holger a while ago that were productive 17:14:23 arnaud: my concern is that the metamodel is complicated - lots of concepts - looks like a Java class hierarchy 17:14:32 s/arnaud/arthur/ 17:14:56 arthur: we need as many terms as are necessary, no more no less 17:15:34 arthur: maybe we should have a group to hash this out 17:15:49 arnaud: let's first try to iron out some notions here 17:17:01 arthur: there is still evidence of complex metamodelling in the spec and the vocabulary 17:17:08 q+ 17:17:09 +q 17:17:13 ack hknublau 17:17:54 holger: this is very detailed work so it is difficult to agree on in general calls and emails 17:18:13 holger: topics like abstract classes can be separated out 17:19:01 holger: I made an update to Arthur's proposal, but I haven't seen any responses in the mailing list 17:19:47 arnaud: it is possible to just have side meetings or we can set up an official task force 17:19:49 ack simonstey 17:20:55 simon: both of these issues have interest to Siemens 17:21:58 Things are moving along here and I don't have any specific concerns at the moment 17:22:07 arthur: how are we going to move forward? 17:22:28 s/arthur/Arnaud/ 17:22:58 arnaud: If there is any email communication use the mailing list and have a special tag 17:23:47 arthur: I would like to have Skype calls on this topic 17:24:09 arnaud: That could work - the result would be a proposal to the group as a whole 17:24:33 arnaud: can you push on this? 17:24:48 arthur: yes, we won't start until after vacations 17:25:06 arnaud: I just want to know that someone will push on this 17:25:33 holger: is there any immediate feedback right now? 17:26:03 holger: this is involved with the RDF file 17:26:09 q+ 17:26:21 ack pfps 17:26:32 arnaud: we have three participants right now 17:26:56 pfps: holger said this is about the turtle file. 17:27:20 q+ 17:27:22 pfps: holger said that this is about the turtle file, but I would hope that the file is just a reflection of some underlying need 17:27:26 ack aryman 17:27:37 ... that's true to some extent, but one would hope that the turtle file is a reflection of some underlying need 17:28:16 arthur: the turtle file is not something that users need to know, but does impact extensions 17:28:50 q+ 17:29:09 pfps: one hopes that the turtle file mirrors the kind of things one needs to know about when writing core SHACL 17:29:11 ack aryman 17:29:13 pfps: it would be very strange if the turtle file didn't have shape or constraint in it 17:29:29 arthur: the turtle file defines the vocabulary 17:30:00 arthur: some reflects the basic design of SHACL and thus is of interest to everyone who writes SHACL 17:30:24 arthur: other is only of interest when writing extension functions 17:30:25 q+ 17:30:38 arnaud: any comments? 17:30:40 ack pfps 17:31:04 pfps, 17:31:18 pfps: minimality is something to be desired here 17:32:18 arnaud: arthur will set up a meeting with at least arthur, holger, and simon and announce on the mailing list 17:32:43 ACTION to arymn to set up a meeting with at least arthur, holger, and simon and announce on the mailing list 17:32:43 Error finding 'to'. You can review and register nicknames at . 17:33:15 ACTION: aryman to set up a meeting on metamodel with at least arthur, holger, and simon and announce on the mailing list 17:33:15 Created ACTION-33 - Set up a meeting on metamodel with at least arthur, holger, and simon and announce on the mailing list [on Arthur Ryman - due 2015-12-22]. 17:34:13 Topic: ISSUE-47 -- Can SPARQL-based constraints access the shape graph, and how? 17:34:27 arnaud: there are several issues related to SPARQL 17:34:42 arnaud: let's discuss those in a holistic way 17:34:51 issue-47 17:34:51 issue-47 -- Can SPARQL-based constraints access the shape graph, and how? -- open 17:34:51 http://www.w3.org/2014/data-shapes/track/issues/47 17:35:05 pointer to the group?? 17:35:12 https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-47:_.24shapesGraph 17:35:24 The general setup is 17:35:34 SPARQL issues 17:35:35 accessing the shapes graph during validation ISSUE-47 17:35:37 requiring sh:hasShape ISSUE-63 17:35:38 requiring SPARQL function definition on the fly ISSUE-109 17:35:40 fully specifing the SPARQL language binding - what variables are rebound, what auxiliary functions are available, etc. 17:35:54 http://www.w3.org/2014/data-shapes/track/products/6 17:36:18 q+ 17:36:24 ack hknublau 17:37:02 holger: the last time I looked at this issue there were ......... 17:37:27 holger: if someone votes against this ....... 17:37:52 https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-47:_.24shapesGraph 17:37:59 arnaud: I hear you saying that people who vote against this should provide a solution 17:38:26 q+ 17:38:30 ack pfps 17:38:37 aryman_ has joined #shapes 17:38:40 q+ 17:39:47 pfps: I am prepared to extract from my SHACL implementation to show that it is possible to do SHACL without accessing the shapes graph during validation 17:40:06 q+ 17:40:24 ack aryman_ 17:41:07 q+ 17:41:09 it may be that certain aspects of the SHACL syntax could be changed for the better if shapes graph access is not mandated 17:41:27 arthur: non-SPARQL implementations may not need this access, as well 17:41:47 q- 17:41:59 ack pfps 17:41:59 arthur: access to the shapes graph is a language extension issue 17:42:02 q- 17:42:40 arthur: it may be that access to the shapes graph is convenient for SPARQL implementation 17:43:08 audio is too choppy to understand 17:43:11 holger: no .... 17:43:59 We need to separate core and extensions 17:44:08 for core language, yes we can hard-code everything 17:44:17 for extensions, the general mechanism is needed IMHO. 17:44:39 At the same time, having $shapesGraph provides a very elegant and compact default implementation of the core language. 17:45:00 q+ 17:45:23 ack Dimitris 17:46:05 q+ 17:46:07 dimitris: there is a tradeoff betwen implementation convenience and specification ... 17:46:24 arnaud: so should the access be mandated 17:46:32 ack aryman_ 17:46:50 dimitris: are the examples important enough 17:48:07 pfps: to get around the need of accessing the shapes graph you need to build up a larger SPARQL query 17:48:16 arnaud: how to make progress 17:48:19 q+ 17:48:37 I don't see how that could work with general sh:sparql 17:48:42 ack pfps 17:48:45 I disagree with Arnaud's assessment. 17:49:01 arnaud: it seems to me that access is (only) useful, not necessary 17:49:03 There are plenty of real-world use cases where this is needed. 17:49:41 pfps: those saying that access is not required need to prove their point 17:50:16 q+ 17:50:25 ack aryman_ 17:50:30 pfps: I will extract information towards that point 17:50:40 I think Dimitris' concern about SPARQL endpoints can be addressed by clarifying that SPARQL endpoints do not cover all of SHACL, but a profile only. 17:50:59 arthur: if you don't require access to the shapes graph then you need to do macro expansion 17:51:30 arthur: you really need text expansion 17:51:31 ACTION: pfps to send info on how to do without $shapesGraph 17:51:31 Created ACTION-34 - Send info on how to do without $shapesgraph [on Peter Patel-Schneider - due 2015-12-22]. 17:51:56 hknublau, I would prefer to keep shacl interoperable but if people believe otherwise I will not object 17:52:04 arthur: once peter has come back we can look at the issue again 17:52:09 q+ 17:52:13 q+ 17:52:25 ack pfps 17:52:45 pfps: I don't know what interoperability means in this context 17:52:57 It's easy to detect which constraints use $shapesGraph. 17:53:04 dimitris: this is only for SPARQL endpoints 17:53:05 You can then decide to not validate this constraint. 17:53:46 q+ 17:53:52 ack aryman_ 17:53:54 We already have fatal errors. Yes, wordsmithing would be my preference. 17:54:25 arthur: interoperability is very important, sh:hasShape is one aspect 17:54:55 arthur: can SPARQL endpoints that have no SHACL support be used in SHACL 17:55:10 Many shapes require background knowledge from certain named graphs, e.g. code look ups. An endpoint may not be able to access those anyway. 17:55:28 arthur: have we established that SHACL can be done on SPARQL endpoints 17:55:55 we only have http://w3c.github.io/data-shapes/data-shapes-ucr/#uc38-describing-and-validating-ldp that's somehow mentioning endpoints 17:55:59 pfps: there was a resolution to the contrary 17:56:28 http://www.w3.org/2014/data-shapes/track/issues/74 17:56:54 q+ 17:57:05 ack aryman_ 17:57:08 pfps: there is a difference between SPARQL endpoints that have no SHACL support and SPARQL endpoints that have some SHACL support 17:57:38 arthur: there are ways of getting around write acces 17:57:40 q+ 17:57:46 ack pfps 17:58:21 pfps: if all you can do is execute a query then an endpoint won't do the trick 17:58:30 Even with SPARQL endpoints there is the work-around of evaluating the SPARQL endpoint from the client's SPARQL engine (SPO) 17:58:51 arthur: a modified endpoint could have a facility for accepting a "temporary" graph - that not write access 17:59:15 Is there a toll-free number to call from Germany? 17:59:32 arthur: we haven't discussed the protocol for accessing a remote SHACL endpoint 17:59:38 arnaud: correct 17:59:50 topic: ISSUE-63 -- sh:hasShape 17:59:50 ISSUE-63 -- Nested shapes: sh:hasShape function versus recursive SPARQL code generation -- open 17:59:50 http://www.w3.org/2014/data-shapes/track/issues/63 18:00:04 arnaud: let's shift to ISSUE-63 18:00:36 https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-63:_sh:hasShape 18:00:37 arnaud: Holger says that sh:hasShape is needed 18:00:38 q+ 18:00:45 ack pfps 18:01:41 pfps: recursive shapes require some extension to SPARQL, however there is no working definition of how sh:hasShapes works, and without such how can we proceed 18:02:00 q+ 18:02:07 We could at least agree on the general direction. I know that some aspects are still open, such as details of recursion. 18:02:24 ack aryman_ 18:02:38 arthur: this gets back to needing a formal spec 18:03:32 arthur: a formal definition of sh:hasShape will allow a decision on where to allow it 18:04:08 arnaud: there is a recurrant pattern - general direction vs full specification 18:04:13 q+ 18:04:22 ack pfps 18:05:02 pfps: recursive shapes, and particularly using sh:hasShapes has been around for a long time, and problems have been brought up against it, but there is still no working specification 18:05:24 q+ 18:05:28 pfps: how can I vote for something that isn't working 18:05:54 I believe I have a working version, and have no test cases that break. Who can provide tests that break it? 18:06:33 pfps: I haven't seen anything beyond "if you get back to the same place, then fail" that works 18:06:38 ack aryman_ 18:06:51 I have pointed out several problems with the SPARQL DEFINITIONS in the spec 18:07:10 arthur: in the absence of recursion then there are no problems with sh:hasShape 18:07:37 arthur: if there is recursion then there needs to be a formal spec of how sh:hasShape works 18:08:03 arthur: the only work is specing out the context in which sh:hasShape works 18:08:21 arthur: I think that positive recursion does not have to fail 18:08:49 arthur: for full marks we might be able to do something for negation and disjunction 18:09:12 arnaud: peter - your concern is mostly with respect to recursion 18:09:29 q+ 18:10:06 pfps: yes, but there is no way of determining when recursion will no raise its ugly head without running sh:hasShapes, so sh:hasShapes needs to be able to detect recursion 18:10:34 ack aryman_ 18:10:43 pfps: the first implementations of recursion would have just gone into an infinite loop 18:11:31 arthur: we could do a static analysis to look for recursive shapes and give up then 18:11:33 q+ 18:11:55 arthur: that happens before sh:hasShape even gets into the picture 18:12:10 ack pfps 18:12:18 arthur: we could do better and look for runtime recursion 18:12:33 pfps: I vote for static analysis, but that means no recursion 18:13:07 arthur: that can be a starting position, and add recursion if we can figure out how to do it 18:13:31 arthur: are there case were we absolutely have to allow statically recursive shapes? 18:13:54 arnaud: if we put recursion aside, can we agree to sh:hasShape? 18:13:54 recursion comes up a lot in e.g. clinical observations which relate to other observations 18:14:07 q+ 18:14:27 ack pfps 18:14:27 arnaud: I suggest we close the issue by adding sh:hasShape 18:14:50 pfps: sh:hasShape has problems having to do with execution and optimization 18:15:15 pfps: sh:hasShape is a foreign intrusion into SPARQL and is thus likely to not be handled well 18:15:39 pfps: sh:hasShape is not necessary if there is no static recursion 18:15:51 Again, not every implementation MUST support sh:hasShape, only the SHACL Full ones do. 18:15:58 q+ 18:16:10 ack aryman_ 18:16:40 arthur: if there is no recursion then you can just expand shapes into a SPARQL query 18:17:08 arthur: there might be pragmatic problems because the query might be large 18:17:11 I believe it will be easier to optimize if sh:hasShape is present. 18:17:33 PROPOSED: Close ISSUE-63, adding sh:hasShape as proposed understanding that if recursion is added, it will impact sh:hasShape 18:17:40 But of course this requires some implementation burden. But SHACL was invented after SPARQL. 18:17:56 +1 18:18:01 +1 18:18:22 +1 18:18:57 -0 18:19:15 +-0 18:19:47 q+ 18:19:52 eric: what does it mean to have sh:hasShape? 18:19:54 q+ 18:19:59 ack aryman_ 18:20:19 arthur: my interpretation is that in the SPARQL language binding you will have available to you sh:hasShape 18:20:37 +1 18:20:51 arnaud: holger has said that this is only for the SPARQL extension mechanism 18:20:53 RESOLVED: Close ISSUE-63, adding sh:hasShape as proposed understanding that if recursion is added, it will impact sh:hasShape 18:20:56 ack pfps 18:20:59 q- 18:22:42 I was just asking if there is any German phone number for me to use instead of the lousy internet connection from the village that I am in. 18:23:00 I will look on the web page... 18:28:17 that's an interesting question others have asked before 18:28:54 webex for sure has international numbers but I don't know whether they work for our call 18:28:57 it's worth a try 18:29:47 https://support.webex.com/MyAccountWeb/needsupport.do?userType=ht 18:29:59 maybe eric knows? 18:30:45 we have a MIT number and I don't know whether this will work 18:31:53 I have tried the number of that link but it takes me to the company itself (sales etc). No join number. 18:32:36 oh 18:32:52 ah right, I didn't realize that's what it was 18:36:28 back 18:36:29 back 18:36:34 back 18:36:52 still choppy Holger 18:36:58 Ok, I can scribe then I guess :) 18:37:44 scribe: hknublau 18:38:23 Not really on the fly 18:38:27 what is the ISSUE #? 18:38:35 topic: ISSUE-109 function calling 18:38:35 issue-109 -- SHACL requires that SPARQL implementations be able to call functions defined on the fly -- open 18:38:35 http://www.w3.org/2014/data-shapes/track/issues/109 18:38:50 They just need to be accessible before the SHACL engine starts, i.e. when the shapes graph gets set. 18:39:03 I think so, i.e., that the current draft requires that SPARQL code can call functions that are defined in SHACL shapes 18:39:59 pfps: when you do a SPARQL validation run, it is required that the SPARQL code is available as a function. 18:40:26 http://w3c.github.io/data-shapes/shacl/#functions 18:40:32 hknublau: I already said above, yes to a certain extent. 18:40:50 ... this extends vanilla SPARQL 18:41:08 ... but this is an extremely useful feature that has proven useful in practice many times. 18:42:05 arnaud: I see a pattern emerging, every time Holger states they are really useful, while others hesitate to extend SPARQL. 18:42:16 so in your SHACL shapes you can call SPARQL functions that correspond to your SHACL functions 18:42:27 ... what should be our general strategy here? 18:42:47 q+ 18:42:48 again, I have use cases where I can make use of sh:Function 18:43:13 ack aryman_ 18:43:46 aryman: claims to be more general than for SPARQL, but I don't see this as generally useful. 18:43:58 ... so why does it have to be generic? 18:44:26 hknublau: I need to think about it. But can we at least agree on it for SPARQL? 18:44:54 q+ 18:44:57 ... one use case that we have in TopBraid is to have SPARQL functions with a JS body. 18:44:58 q+ 18:45:00 ack aryman_ 18:45:05 q+ 18:45:52 aryman: Looks like a SPARQL language feature, probably very useful but maybe scope creep - it is our mission? 18:46:13 hknublau: There is no SPARQL WG that could handle this. I don't want to wait 5 years. 18:46:15 ack pfps 18:46:16 The built-in functions (e.g., sh:hasShape) are needed to implement SHACL (or at least they should be). The function mechanism is a convenience. 18:46:30 pfps: I agree with arthur. 18:46:38 ack Dimitris 18:47:23 Dimitris: Unsure about this feature. Useful but complex. 18:47:46 hknublau: I think implementation burden is not much. 18:47:53 q+ 18:48:20 ack ericP 18:49:05 ericP: If we were adding stuff in SPARQL, so we should do a proper job. 18:49:30 +q 18:50:19 ... my fear is that if we go for this then we may be making SPARQL architecture decisions that may make future SPARQL extensions harder. 18:50:27 ack simonstey 18:51:01 well, I do agree with the idea of not extending SPARQL piecemeal, but that is separate from violating RDFS specs 18:51:29 simonstey: Even if SPARQL 1.2 would implement this, there is no standard way to connect SPARQL queries with your ontologies. With SHACL you can store these functions and share them as RDF. 18:51:52 q+ 18:52:10 ... we have used them and see them as valuable extensions. We may interfere with future SPARQL WGs, but I would be grateful for that feature. 18:52:34 Arnaud: We need straw poll. 18:52:40 ack pfps 18:53:08 q+ 18:53:17 pfps: One possibility is to have functions but execute them as macro expansion. 18:53:42 Arnaud: Isn't this an implementation issue? 18:53:58 pfps: In your SPARQL code you state the name of the function. 18:55:00 this does not work with multiple functions in filters 18:55:02 ... Alternative could be to have meta-function (did the scribe get this?) 18:55:23 and function nesting 18:55:49 it would be possible to say something like sh:callfunction, which obviates the need for extending SPARQL at the expense of some extra bits of syntax 18:56:42 STRAWPOLL: a) keep sh:Function, b) drop sh:Function, c) keep sh:Function but add callSHACLFunction as pfps suggested 18:57:05 another problem with functions, however, is handling functions that call other SHACL functions, and from there infinite recursion 18:57:43 aryman: Would be better to regard this as syntactic sugar, i.e. if syntax expansion was always possible. 18:58:26 q+ 18:58:52 ack aryman_ 18:59:05 there are several ways to do functions without requiring an extension to SPARQL 18:59:22 hknublau: How would this work with FILTER clauses. We also use this a lot in BINDs, and nested SELECT queries cannot access incoming variables. 18:59:37 ... Our use cases definitely go beyond this. 18:59:40 ack pfps 19:00:07 pfps: SHACL functions can call other SHACL functions. 19:00:30 ... things are shoved in, and details have not been looked at. 19:00:55 hknublau: This feature has been in production for many years, despite potential theoretical issues. 19:01:00 q+ 19:01:10 ack pfps 19:01:18 ... functions are also useful to describe the semantics (validation functions). 19:02:06 pfps: Dimensions: How to call them. What should be the capabilities of these functions. 19:02:49 ... we could disallow recursion in functions. But decisions have to be made there. 19:03:15 hknublau: I find it very difficult to defend my position without being able to talk. 19:05:03 pfps: Requires extensions to SPARQL. I would be astonished if any SPARQL engine currently allows users to inject functions to their engines. 19:05:57 hknublau: AllegroGraph supports SPIN functions, so point disproven. 19:06:25 q+ 19:06:31 ack aryman_ 19:06:35 Most SQL engines support stored procedures. 19:07:04 aryman_: Are you assuming that all input arguments are bound? 19:07:19 hknublau: Functions can have optional arguments. 19:07:33 ... but they can check bound(?x) in their body. 19:07:51 but can calling a function result in any unbound arguments becoming bound? 19:08:07 hknublau: No, only in BINDs. 19:08:19 ... BIND (ex:myFunction() AS ?result) 19:09:03 so in all cases, could we not expand the SPARQL body inline (in the absence of other functions being called in the body?) 19:09:11 Arnaud: How to make progress. Some people seem to question the whole idea of functions. 19:09:51 STRAWPOLL: a) keep sh:Function, b) drop sh:Function 19:09:57 a) +1 b) -0.9 19:10:23 a) +1 b) -1 19:10:37 a) 0 b) 0 19:10:39 a) -0 b) +1 19:10:56 a) 0+ b) 0 19:11:05 a) -0.5 b) +0.5 19:11:18 a) 0 b) 0 19:12:23 Arnaud: Looks like not enough people are against it. Next question: how does it have to be invoked? 19:12:59 q+ 19:13:01 hknublau: Syntax is much easier if static (as defined right now), also allows static analysis and optimizations. 19:13:04 ack aryman_ 19:13:41 aryman_: If this is just a macro you can just inline it. 19:14:25 hknublau: Sometimes (rarely) recursion yes. 19:14:39 ... a real problem is that many of these functions are aggregation functions, COUNT etc. 19:14:45 ... these require nested SELECTs. 19:14:55 ... nested SELECTs cannot access outside bound variables. 19:15:15 ... so you cannot pass parameters into them when expanded as macros (done). 19:15:33 so what happens on a function recursion, what happens on data loops? 19:15:45 nested SELECTs can access whatever variables you put in the result list 19:15:48 ... But I could live with disallowing recursion for now until someone proves how this works. 19:16:23 does SPIN allow function recursion? 19:16:54 Yes SPIN allows it. The engine may simply crash. 19:18:13 q+ 19:18:24 ack aryman_ 19:18:46 then there is the issue of calling functions when the arguments are unbound 19:19:01 aryman_: We could use static analysis to avoid infinite loops. 19:19:42 hknublau: SPARQL has a built-in mechanism for functions to fail (return unbound). 19:20:09 PROPOSED: prohibit recursion in sh:Function 19:20:24 but how do SHACL functions work? they are not defined as macro expansion 19:20:49 +1 19:20:51 in the absence of recursion could they not be defined by macro expansion? 19:20:54 0 (We can later allow this, if someone has a worked out proposal). 19:20:59 +1 19:21:17 +1 19:21:19 +1 19:21:19 +-? not sure how this would work, but ok if it does 19:21:22 This is more than macro expansion, not just syntactic sugar. 19:21:37 how? 19:21:49 0 19:22:01 RESOLVED: Prohibit recursion in sh:Function 19:22:32 FILTER (ex:exampleFunction(?value, 2) = 42) 19:22:43 @aryman_: Nested SELECTs etc. (Needs better bandwidth to discuss). 19:23:20 something like sh:callFunction(ex:exampleFunction,?value,2) 19:23:24 callSHACLfunction(ex:exampleFunction, ?value, 42) 19:23:37 s/42/2/ 19:23:39 What is the advantage of the metafunction? 19:24:02 The first argument could be a variable, making this very unpredictable. 19:24:22 pfps: This would be similar to sh:hasShape. 19:24:25 the metafunction makes this look like the sh:hasShape solution 19:24:54 the SHACL processor could make the replacement at execution time 19:25:00 ... At least these are the only SPARQL extensions 19:25:12 hknublau: The syntax is not user friendly. 19:25:27 q+ 19:25:41 ack aryman_ 19:25:42 ... Many SPARQL engines provide all kinds of built-in extension functions. 19:25:57 ... the developers don't see this as a problem. 19:26:20 PROPOSED: Close ISSUE-109, by requiring sh:Functions to be invoked via a new wrapper sh:callFunction() 19:26:34 -1 19:26:51 0 19:26:55 0 19:26:56 is this wrapper function will just a macro or can it participate in filter / bind statements? 19:26:59 0 19:27:03 +0 19:27:16 s/will// 19:27:27 +1, it's better than the alternative, and it's the same sort of syntax as used for embedded shapes 19:29:05 +1 for macro expansion / 0+ for general case 19:29:51 Dimitris: Some functions can be called in complex expressions with && and ! 19:31:17 ... injecting code doesn't always work in FILTERs and BIND. 19:31:27 FILTER (ex:exampleFunction(?value, 2) = 42) vs FILTER (sh:callFunction(ex:exampleFunction,?value,2) = 42) 19:32:05 if one of these works then so should the other 19:32:21 pfps: No difference in behavior. 19:33:14 hknublau: I enumerated some problems already: 19:33:23 ... not user friendly 19:33:38 ... injection of functions as variables 19:33:47 embedded shapes look like sh:hasShape(...,shape,...) so this should be made more user friendly as well? 19:33:54 ... I don't think there is any implementation difference. 19:33:59 q+ 19:34:06 as in shape(...,...)? 19:34:13 ... engines already have many functions, and functions are an official extension point. 19:34:19 ack Dimitris 19:35:06 pfps: Not much difference in terms of lines of code for a simple implementation. 19:35:38 ... however, now we can have function invocations against random URIs 19:36:09 ... we use sh:hasShape, why don't we use the same trick there? 19:36:30 hknublau: How would the SPARQL syntax of that look like? 19:36:46 there may be good reasons not to do this for sh:hasShape, but I don't know off one offhand 19:36:46 ... are they also just function calls? 19:37:30 ... I also believe there are cases where ?shape in sh:hasShape must be a variable. 19:38:28 q+ 19:39:01 pfps: Let me act conservatively yet again. 19:39:26 ... we are adding something significant to SHACL that some people want, but there are lots of negatives. 19:39:41 ... dropping recursion helps a bit. 19:39:57 ... I am not gonna vote against it, despite not liking it. 19:40:29 ack aryman_ 19:40:45 # raw source code SELECT ?subject WHERE { ?subject ex:myProperty ?value . FILTER (ex:exampleFunction(?value, 2) = 42) . } # expanded source code SELECT ?subject WHERE { ?subject ex:myProperty ?value . # begin macro expansion VALUES (?arg1 ?arg2) {(?value 2)} SELECT ?arg1 ?arg2 ?arg1+?arg2 as ?result WHERE { } # end macro expansion FILTER (?result = 42) . } 19:41:08 I think that we should encapsulate the SHACL extensions 19:41:32 hknublau: I don't think this works. I think VALUES are moved to the beginning of the query. 19:41:51 I am not sure. 19:42:07 But this is a complex topic, I cannot answer spontaneously. 19:42:15 We may need to postpone this 19:42:53 PROPOSED: Close ISSUE-109, keeping with the current spec - no wrapper function 19:42:58 +1 19:43:08 0 19:43:12 0 19:43:19 it appears to me that the informal semantics of functions is different from macro-expansion 19:43:28 0 19:43:36 0+ (+1 if we limit Functions to macro expansion) 19:43:43 0 19:43:57 -0, this is a very little improvement in syntax for a decided increase in conceptual complexity 19:44:45 RESOLVED: Close ISSUE-109, keeping with the current spec - no wrapper function 19:48:26 q+ to ask whether this is the still-open problem of specifying the binding mechanism topic: SPARQL language binding 19:48:29 aryman_: SPARQL stuff is all over the place, we need an interface in one place. 19:49:00 more clarity is nice :-) 19:49:26 Arnaud: You are co-editor, what is it that the WG needs to decide? 19:50:17 aryman_: We need to reorganize to separate the general extension mechanism with SPARQL specific bits. 19:50:40 hknublau: Yes I had this separated more clearly earlier, but this made explaining anything very difficult because 19:50:49 ... every example needs something specific, e.g. sh:sparql. 19:51:07 ... but we should look at this in depth and I can talk to Arthur directly. 19:51:59 Arnaud: Sounds like the editors can handle this among them. 19:52:36 q+ 19:52:44 ack pfps 19:52:44 pfps, you wanted to ask whether this is the still-open problem of specifying the binding mechanism and to 19:53:01 pfps: Rework should include prebinding issue. 19:53:20 hknublau: We have hired Andy S. for TQ, I will talk to him about this. 19:53:43 ... yes 19:54:01 ... They still exist. 19:54:32 ... Yes I met them all in London. 19:56:35 Arnaud: I will try to use IBM phone bridge for tomorrow's meeting. 19:56:46 you should first check to see if there is a suitable number for whereever Holger is 19:57:59 yes, I'll ask W3C 19:59:02 i asked. if there is one, MIT's keeping it secret 20:00:32 ok 21:23:16 Dimitris has left #shapes 21:44:50 trackbot, end meeting 21:44:50 Zakim, list attendees 21:44:50 As of this point the attendees have been Arnaud, aryman, ericP, hsolbrig, kcoyle, Dimitris, simonstey, pfps, hknublau 21:44:58 RRSAgent, please draft minutes 21:44:58 I have made the request to generate http://www.w3.org/2015/12/15-shapes-minutes.html trackbot 21:44:59 RRSAgent, bye 21:44:59 I see 3 open action items saved in http://www.w3.org/2015/12/15-shapes-actions.rdf : 21:44:59 ACTION: aryman to draft a semantics doc for the WG to consider, that would complement the current SHACL spec [1] 21:44:59 recorded in http://www.w3.org/2015/12/15-shapes-irc#T16-04-58 21:44:59 ACTION: aryman to set up a meeting on metamodel with at least arthur, holger, and simon and announce on the mailing list [2] 21:44:59 recorded in http://www.w3.org/2015/12/15-shapes-irc#T17-33-15 21:44:59 ACTION: pfps to send info on how to do without $shapesGraph [3] 21:44:59 recorded in http://www.w3.org/2015/12/15-shapes-irc#T17-51-31