See also: IRC log
<BartvanLeeuwen> hi
<Arnaud> +present: Arnaud
<pfps> +present: pfps
<simonstey> https://www.w3.org/2006/tools/wiki/WebExBestPractices#Attendance
<simonstey> Attendance Best Practice: Each participant should type present+ <name> in the irc channel immediately upon joining the call
<pfps> given that Zakim knows who is on IRC, why do we need to enter attendance??
<Arnaud> PROPOSED: Approve minutes of the 4 June Telecon: http://www.w3.org/2015/06/04-shapes-minutes.html
<pfps> status of the approved user stories have not been changed
<pfps> otherwise minutes look OK
RESOLUTION: Approve minutes of the 4 June Telecon: http://www.w3.org/2015/06/04-shapes-minutes.html
meeting next week
<Arnaud> PROPOSED: Based on Doodle Poll the F2F4 in Lille will take place on September 8-10, 2015
RESOLUTION: Based on Doodle Poll the F2F4 in Lille will take place on September 8-10, 2015
Arnaud: To try and streamline our calls, from then on I will drop this agenda item and we will discuss issues or actions as they related to specific item
... in the agenda
<pfps> sounds OK
Arnaud: there was an action for Peter
... to draft what his proposed document would look like
action-27
<trackbot> action-27 -- Peter Patel-Schneider to Write outline of semantics document fragment -- due 2015-06-11 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2014/data-shapes/track/actions/27
<Arnaud> close Action-27
<trackbot> Closed Action-27.
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jun/0060.html
Peter: a formal definition of SHACL includes 2,5 parts
... syntax, semantics
... tried to see where the syntax and the semantics worked all together
... even the simplest parts of the syntax were difficult
... showing what the vocabulary is but it doesn't solve the problem
... we need to collect together the definition of shacl in syntax
... semantics and functions
<hknublau> +q
Holger: asks about how specifications are written
... if there is information in a Turtle file why we need to duplicate it
... his assumption is that SHACL is defined in itself
... in a machine readable form
... to what level do we need to duplicate that information?
... the turtle file contains details about the syntax
... the syntax declares the properties
Peter: there is a number of things...as far as syntax goes maybe...as far as semantics goes you need more than a turtle file
... it is difficult to figure out how much covers the turtle file
... it is necessary to state what is a SHACL graph
... as far as the document is now...there is a disconnection in the HTML and the syntax in the Turtle file
... maybe, one can say that the RDF graph is the definition of SHACL syntax
... it might work. I can't tell by now
... in programming languages the formal defnition includes grammars
... in BNF form
... there needs to be more in the document to describe the syntax...separate from the semantics
... how is it possible to define the semantics in a SHACL shape document
... Holger:the templates define the arguments that they take
Arthur: is this the vocabulary for SHACL?
<TallTed> is the concern that a (which?) Turtle doc content is out of sync with an (which?) HTML doc content? I'm fairly certain that the same information could be fully expressed in either/both...
<TallTed> and it's hard to keep two docs in such sync, so choosing one makes some sense, and if the Turtle is mandatory, that seems the obvious choice.
Holger: yes, there is a link to a Turtle file
<TallTed> +1 arthur
<hknublau> +q
<simonstey> Turtle File: http://w3c.github.io/data-shapes/shacl/shacl.shacl.ttl
Arthur: There can be some transformation mechanism to generate the HTML from the Turtle
Holger: I like that idea because the Turtle file is very important
<Dimitris> *I cannot hear anything from webex, is it only me?*
<Arnaud> dimitris, it seems like it
<Dimitris> *I am back now*
*I couldn't hear Peter*
<Dimitris> *sorry :) *
Peter: I don't care whether the formal defnition is inline or in a separate document...
... what i think needs to be is a way to determine whether a RDF graph is a valid shach graph or not
<hknublau> +q
Holger: the more I think about it, the more I like it...to autogenerate from the Turtle
... some technology to autogenerate all the classes, properties, etc. from the Turtle file
... it requires some work to set up
... but I like the idea
... there are some SPARQL constraints that haven't been formalized yet
thanks
Arthur: a tool where the input is a turtle file, it uses jena to generate the xml file and with xslt it generates HTML
... several vocabularies have been published in that way
Arnaud: there may be some issues yet to address Peter's concern
... but let's move on
<Arnaud> ISSUE-66
<trackbot> ISSUE-66 -- SHACL should not be ill-founded -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/66
Issue: http://www.w3.org/2014/data-shapes/track/issues/66
<trackbot> Created ISSUE-67 - Http://www.w3.org/2014/data-shapes/track/issues/66. Please complete additional details at <http://www.w3.org/2014/data-shapes/track/issues/67/edit>.
Peter: the SHACL spec in the document is ill-founded
<hknublau> +q
Peter: the examples that ilustrate that involve recursion
Holger: given that we are writing a W3c specification it needs to be well founded...but he is not in favour to open the issue because it is not specific enough
Arnaud: we all agree that it should be well founded
Peter: this is a separate issue than "what to do with recursion"
... we can argue that the recursion issue could be solved
<simonstey> did you get my question regarding issue 22?
Peter: I don't believe we should publish a FPWD with an ill founded semantics
Arnaud: it is a saying we should not publish a spec that is broken
Ted: it doesn't seem to be a issue
Peter: should I have made the title as "the current spec is broken" so it could be addressed?
Ted: yes
... and the issue should be more specific with some example
Peter: the question is...there is an example where the current spec doesn't work...and that could be the issue
Arnaud: as it is, the issue is not actionable
Ted: it seems to me that Arnaud sees Issue-66 as a special case of issue-22
Arnaud: we leave it as is by now
sorry for that
<Arnaud> PROPOSED: Close ISSUE-60: Shall SHACL support other extension languages beside SPARQL (like JavaScript)? saying yes, even though we may not define any such extension at this point, the design should allow it.
<hknublau> +1
<simonstey> +1
+1
<BartvanLeeuwen> +1
<pfps> -1
<TallTed> +1
<kcoyle> +.5
<Dimitris> +0.5
<kcoyle> +0.5
<ericP> +1
<Arnaud> aryman: +1
Ted: I don't know what Peter's objection is
Peter: if we had independent languages for SHape Expressions then I would be more in favour of this proposal
... the proposal to alowing different execution models would require those models to do the same thing...
... otherwise we would have non-interoperable definitions
Ted: the analogy was not to stylesheets...it was to script languages...which are independent
... anything you can do in javascript you can do with any other language
... and that's the same here
... the engines that will be created 5 years from now can incorporate javascript
... or whatever
Peter: the proposal as it is written says that if you have sparql body and a javascript body they must do the same thing
Holger: the goal should certainly be that those extensions should implement the same behaviour
... but I don't see as a showstopper...
... we must document that the behaviour must be the same
... but there is no way of doing that
Peter: My major concern is interoperability
... for scripting language they were different languages
... now we have a situation where we don't have an extension language but execution models that have to behave the same way
... my understanding is that any feature in a spec must have some interoperability criteria
<ericP> so we could have two interoperable impls with js support, no?
Ted: right now, we say SHACL extension implemented in SPARQL and we allow for the possibility that there might be another one
<Zakim> ericP, you wanted to say that that we could have interoperabile implementations of a second language addressing different use cases
Peter: SHACL has a specification, it has an extension language that is SPARQL...and the contract if there are future extensions the execution bodys should produce the same error violations
Eric: We have different use cases and different languages
... we could have javascript extensions and they need not have any interaction with other extensions
... we can have use case by use case
Arthur: analogy with web browsers could be the object tag
<TallTed> +1 HTML <object> seems more fitting analog than <script>
Arthur: I don't think that it means that a javascript extension should behave the same as a SPARQL extension
Holger: I am happy to see that it passes
... to say that this is also for the javascript people
... at the same time I'm feeling that Javascript may not be unreasonable
... it's not that difficult
Arnaud: if someone has the energy to do that, great
Holger: if we define javascript as an extension language...it doesn't mean that we need to define the templates in javascript
... otherwise there might be non-interoperable definitions
Peter: If we allow multiple execution languages then interoperability is a nightmare
... we must be careful not to introduce inteoperability issues
Ted: there is a general practice in the web of elegant failure
<Arnaud> PROPOSED: Close ISSUE-60: Shall SHACL support other extension languages beside SPARQL (like JavaScript)? saying no
Ted: if you see something that you don't recognize you don't fail
<hknublau> -1
<TallTed> -1
<pfps> +1
<Dimitris> -0.5
-1
<ericP> -1
<simonstey> -1
<BartvanLeeuwen> -1
<kcoyle> -1
<Arnaud> aryman: -1
Arnaud: Peter, I'm going to have to overrule your objection
RESOLUTION: Close ISSUE-60: Shall SHACL support other extension languages beside SPARQL (like JavaScript)? saying yes, even though we may not define any such extension at this point, the design should allow it.
Arnaud: you have the possibility of filing a formal objection if you want to
<Arnaud> 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
<Dimitris> +q
Dimitris: is this about the extension mechanism or about the core language?
Holger: I believe that we should allow access the whole graph
... it adds a lot of power to users
<Dimitris> +q
Holger: if somebody wants to get rid of those then we need to see a proposal
... some issues like closed graphs depend on this
... I believe keeping it flexible is the best thing
... the only problem is when you access to a remote sparql endpoint
... then you can't return the original graph again
... there are so many implementations where this is not a issue
Dimitris: my point is that if we aim to have a single spec then SHACL should be used in all the cases
... we must specify how to access to the graph
Peter: there are 2 issues
... whether access to the shapes graph is convenient
... the other one is if it is necessary
... I think it is not necessary
... one could implement however one wants it
... this issue is about accepting the SHAPE graph from the SPARQL code
... it is going to be very hard to correctly run it in many cases
<hknublau> +q
Arthur: in XSLT there is something similar
... it also raises the issue about the compact syntax
... I think it can simplify programming if you have access to the shape graph
Holger: the compact syntax can be compiled to a temporary graph
<BartvanLeeuwen> thx bye
<Arnaud> trackbot, end meeting