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