IRC log of shapes on 2015-12-15

Timestamps are in UTC.

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