RDF Data Shapes Working Group Teleconference

11 Jun 2015


See also: IRC log


simonstey, Arnaud, kcoyle, BartvanLeeuwen, pfps, hknublau, labra, dimitris, aryman, TallTed, ericP


<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

Minutes from last week

<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

Next F2F

<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

Tracking of actions and issues

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

SHACL formal definition

Arnaud: there was an action for Peter
... to draft what his proposed document would look like


<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


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

SHACL issues

<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


<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


<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

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 4 June Telecon: http://www.w3.org/2015/06/04-shapes-minutes.html
  2. Based on Doodle Poll the F2F4 in Lille will take place on September 8-10, 2015
  3. 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.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2015/06/19 00:14:49 $