See also: IRC log
<pfps> Greetings.
<Labra> zaim, [IPcaller] is labra
<TallTed> Arnaud1 - you may want to nick-shift, to make the minutes happier
<Arnaud> scribe: Dimitris
Arnaud: Let's start
Arnaud: approval of minutes from last week
<pfps> Minutes look fine to me :-)
<Arnaud> PROPOSED: Approve minutes of the 16 April Telecons: http://www.w3.org/2015/04/16-shapes-minutes.html
<Arnaud> APPROVED: Approve minutes of the 16 April Telecons: http://www.w3.org/2015/04/16-shapes-minutes.html
-- minutes approved
Arnaud: we have one user story not approved, Arthur any progress?
<kcoyle> +q
<pfps> Is this S40 or some requirement?
<Arnaud> S40
<Arnaud> S40 Describing Inline Content versus References
aryman: Peter is correct, this user story does not necessarily lead to validation but that's not the whole meaning of Shapes
<pfps> Is this a requirement or a user story??
kcoyle: this is definitely a requirement we have in DC
... we need to know if the value exists of we need to dereference
... it is important for us to have this
pfps: My concerns have been validated, is confusing if this is a requirement or a user story.
aryman: Indeed parts are worded as requirement, I can adjust to a user story
Arnaud: update the story with new text and we can vote for approval
pfps: take what Karen wrote and put it in front
Arnaud: Anything the UCR editors want to add?
<pfps> As far as I know, the editors' job is to edit the Editor's Draft.
Arnaud: you are free to keep working on the document
... when you feel you have an improvement we can re-publish
<Arnaud> ISSUE-46?
<trackbot> ISSUE-46 -- Support for RDF Collections? -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/46
UNKNOWN_SPEAKER: any gaps you find in the document bring them to the working group
cygri: one of the stories that mention rdf lists and I was planning to go through the requirements and see if this is captured. I am willing to propose requirements to capture RDF collections
<pfps> Fine by me to include requirements for RDF collections/lists
<Arnaud> PROPOSED: Open ISSUE-46: Support for RDF Collections?
<cygri> +1
<Labra> +1
<TallTed> +1
<kcoyle> +1
<pfps> +1
+1
<SimonSteyskal> +1
<aryman> +1
RESOLUTION: Open ISSUE-46: Support for RDF Collections?
<cygri> ACTION: cygri to add requirement(s) for RDF collections to address ISSUE-4 [recorded in http://www.w3.org/2015/04/23-shapes-minutes.html#action01]
<trackbot> Created ACTION-19 - Add requirement(s) for rdf collections to address issue-4 [on Richard Cyganiak - due 2015-04-30].
<Arnaud> PROPOSED: close ISSUE-35 per Jose's suggestion to add a requirement as detailed in email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Apr/0218.html
<pfps> +1
<Labra> +1
<SimonSteyskal> +1
<TallTed> issue-35?
<trackbot> issue-35 -- Language-tags -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/35
+1
<TallTed> +1
<Labra> +q to ask who is going to add the requirement
<aryman> +1
<Zakim> Labra, you wanted to ask who is going to add the requirement
labra: who is going to split the requirement? I am willing to do this
RESOLUTION: close ISSUE-35 per Jose's suggestion to add a requirement as detailed in email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Apr/0218.html
<michel> +1
Arnaud: Jose will take the action item to do this
<pfps> No Eric and nothing added to the requirement on the wiki page
Arnaud: closed shapes requirement is not approved yet
<Arnaud> 2.6.11 Expressivity: Closed Shapes https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes
aryman: Server should not reject unrecognised content. It should identify it.
<pfps> I'm still waiting for a workable specification of what closed shapes might mean.
TallTed: I approve of the concept of the requirement, but I cannot approve as currently worded
<pfps> http://www.w3.org/2015/ShExpressivity#coverageEtc is very tied to a particular version of ShEx
<SimonSteyskal> i meant regarding the general idea of closed shapes
<Arnaud> ACTION: ericP update description of 2.6.11 Expressivity: Closed Shapes to address concerns expressed to date [recorded in http://www.w3.org/2015/04/23-shapes-minutes.html#action02]
<trackbot> Created ACTION-20 - Update description of 2.6.11 expressivity: closed shapes to address concerns expressed to date [on Eric Prud'hommeaux - due 2015-04-30].
<cygri> Arnaud, did we skip another raised issue, #45?
Arnaud: no, I deferred it to the SHACL section of the agenda, which is now
<Arnaud> ISSUE-45?
<trackbot> ISSUE-45 -- Should SPARQL be a built-in extension language -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/45
Arnaud: we leave this open for now until Erik works on it
... There was a lot of discussion even for what built-in means
<pfps> I'm in favour of opening ISSUE-45
<aryman> +1 for opening ISSUE-45
Arnaud: should we open this? maybe people want to clarify the description
<cygri> ISSUE-45?
<trackbot> ISSUE-45 -- Should SPARQL be a built-in extension language -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/45
<Arnaud> PROPOSED: Open ISSUE-45, Should SPARQL be a built-in extension language
<cygri> +1
<pfps> +1
<Labra> 0
<TallTed> +1
<hknublau> +1
<aryman> +1
+1
<kcoyle> +1
<michel> +1
<SimonSteyskal> 0
RESOLUTION: Open ISSUE-45, Should SPARQL be a built-in extension language
Arnaud: we have a long list of open issues
<Arnaud> ISSUE-30?
<trackbot> ISSUE-30 -- Are shapes and data in the same graph? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/30
Arnaud: I suggest we talk about ISSUE-30
cygri: this is one of the differences between the various proposals. This is a yes / no option
... option 1: data and shapes are in the same graph
... option 2: are in the same dataset but in different graphs
... option 3: the don't need to be in the same system
Arnaud: in the 3rd option the spec will be silent on this?
<pfps> As far as I can see, data and shapes in the same graph rules out quite a number of use cases, unless SHACL has to construct union graphs whenever the data and the shapes come from different sources.
cygri: we coudn't assume they are in the same dataset
pfps: option 1 is impossible for most use cases. This rules-out option 2 as well. The only viable option is option 3
... we can either require to be different or be agnostic and I think being agnostic is better
cygri: why is option 2 ruled out?
pfps: when I use an external dataset I would have to copy the whole dataset
... for example I would have to copy the whole DBpedia
Aryman: option 1 is unworkable
<hknublau> +q
*I missed arthurs last comment*
hknublau: option 2 is working
+q
<aryman> my comment is that this is a language binding issue
hknublau: it can use a different strategy in other cases
<aryman> the question is "What data does the SHACL engine has access to?"
hknublau: we just need to create a graph interface and it is implementable
<aryman> The SHACL engine has access to the graph being validated, and the definition of the Shape
hknublau: engines can optimize
dimitris: I am option 3, except ShEx shapes everything is implementable
and for ShEx shapes it depends on the definition details
<Labra> +q
Arnaud: which option do you prefer or are you neutral
cygri: The current spec uses option 2. Option 3 is easier to specify in the document
... option 2 gives you a lot of power in writing templates
... which pretty nice
... option 3 limits what you can do in templates
+q
scribe: the template would not have flexibility to check the graph
... and get all information needed
<pfps> Option 2 requires support, option 3 doesn't, which is one reason that I prefer option 3
scribe: it is difficult to go into details now
labra: I am in favour of option 3
... my implementation of ShEx supports SPARQL endpoints and it is better to have the freedom
<cygri> Option 2 and 3 are equally agnostic.
aryman: extension like SPARQL are not RDF
... and cannot be queried
cygri: the language specific extension would be able to query the shapes
aryman: for instance javascript would we have predefined (magic) variables that we have to rely on?
magic variables, triple or functions
dimitris: templates can be defined depending on the local setup and could be able to read the shapes or the data graph
cygri: templates should be global and exchangable
... Arthur, this is SPARQL specific, even we we say something for SPARQL we might define something completely different for javascript
aryman: the issue should be how do you the context to the extension mechanism
... and SPARQL may not be the only language that can use to define extensions
<Arnaud> PROPOSED: Close ISSUE-30 making SHACL agnostic on this point
aryman: and we shoudn't rely on SPARQL only
<SimonSteyskal> 0
<Labra> +1
<pfps> +1
+1
<kcoyle> +1
<aryman> +1
<TallTed> +1
<hknublau> -1 I don’t see how this could work
hknublau: this leave the topic undefined. How can we access the shapes graph?
pfps: I am confused on your proposal
arnaud: no, shacl is agnostic on the shapes and data graph
<pfps> The proposal is then to make SHACL admit the possibility that the data graph and the shape graph are completely separate, i.e., queries against the data graph might not have any access to the shape graph.
<TallTed> draft PROPOSAL: Close ISSUE-30 making SHACL agnostic as to whether ShapeGraph is contained within Target DataSet -- permitting either. We will later determine how to specify which is the current case, and how mechanisms work with the two...
arnaud: I tried to capture what people said which is option 3
<pfps> I like Ted's restatement
aryman: draft proposal: Specify how invocation parameters and context variable are made available to custom constraints written in SPARQL, or other languages
<cygri> draft PROPOSAL: Close ISSUE-30 and instead raise a new one: Can SPARQL-based constraints access the shape graph, and how?
<hknublau> +1 to cygri, or just rename the current issue
<pfps> Ted's draft proposal doesn't say anything about SPARQL, so I don't see why it needs Arthur's kind of change
<Arnaud> PROPOSED: Close ISSUE-30 making SHACL agnostic as to whether ShapeGraph is contained within Target DataSet -- permitting either. We will later determine how to specify which is the current case, and how extension mechanisms work with the two
<cygri> -1
<hknublau> +q
cygri: this implies that the extension mechanisms are not part of SHACL
<TallTed> draft PROPOSAL: Close ISSUE-30 making SHACL agnostic as to whether ShapeGraph is contained within Target DataSet -- permitting either. We will later determine how to specify whether the current ShapeGraph is within DataSet, and thus how SHACL and any extension mechanism(s) can act on that specification.
<pfps> -1 to Arnaud's proposal
hknublau: In my proposal I define the function hasShape() which is independent
<pfps> In my view a pure Option 3 is workable, and proposals that presuppose a mechanism to access the shapes from the data graph do not ft into Option 3
cygri: we could close ISSUE-30 and raise an issue with the other question
<pfps> richard: you could just enter the new issue right now, so that we can see what it would look like
I also think option 3 is workable
<Arnaud> PROPOSAL: Close ISSUE-30 as is/unanswered
<hknublau> @pfps Option 3 is throwing away too much useful stuff, like RDFS not be able to query classes
<aryman> +1
<TallTed> +1
<SimonSteyskal> +1
<kcoyle> +1
<cygri> +0.1
<Labra> +1
<hknublau> +1
0-
<cygri> I plan to immediately raise a new issue: “Can SPARQL-based constraints access the shape graph, and how?”
RESOLUTION: Close ISSUE-30 as is/unanswered
cygri: I am not interested in javascript
... for the high level language it is not meaningful to ask this
tallted: if we ask this for SPARQL only people might misinterpret
<cygri> Ted, raise your own bloody issue ;-)
arnaud: Ted, if you don;t like this you can object to opening this
<Arnaud> ISSUE-27?
<trackbot> ISSUE-27 -- Can extension constraints be used in the high-level language? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/27
<kcoyle> yep
arnaud: are we free to mix extensions with the high level vocabulary?
aryman: I think that yes we want to be able to define template used in a similar manner as the high level languges
<Arnaud> PROPOSED: Close ISSUE-27 by saying yes: extension constraints can be used in the high-level language
<pfps> +1
<hknublau> +1
<TallTed> +1
+1
<SimonSteyskal> +1
<kcoyle> +1
<Labra> 0
<cygri> +1
<pfps> How do closed issues link back to resolutions?
<aryman> +1
<pfps> OK, it's all manual
<pfps> Boo to tracker, then
arnuad: I manually close the issues with links to resolutions
RESOLUTION: Close ISSUE-27 by saying yes: extension constraints can be used in the high-level language
<Arnaud> ISSUE-23?
<trackbot> ISSUE-23 -- Shapes, classes and punning -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/23
arnaud: in the F2F meeting we discussed about using something like punning
pfps: Not so easy now. I am not sure if punning is going to help any more
... in rdf we cannot say that shapes cannot be classes, we can just add a type arc
... the question is if it has a special meening
aryman: we can't prevent people from stating a shape is a class
<pfps> To me the issue boils down to whether being a class is somehow special for SHACL shapes (or other SHACL stuff)
<cygri> the question is: do we want to encourage it.
arnaud: Holger's initial proposal relied on the type arc
<pfps> Yes, whether rdf:type from a node to a shape is special to SHACL is part of this issue.
<pfps> The class-related link rdfs:subClassOf is also involved here.
cygri: my view hasn't changed much. It is correct to say that we cannot prevent people to use shapes as classes
... Should the spec take a stand on this? should we consider this as a valid way to do this
<pfps> To me, it's not whether this is a good thing or a bad thing. It is whether there are any SHACL consequences.
cygri: I would like us to enable us to be able to have a single resource for a class and a shape
<hknublau> +q
hknublau: I would find it more productive to look at specific proposals
... what we discuss now looks unspecific
TallTed: similar feeling. We have a huge pile of questions here
... it is difficult to make a way.
... well-defined classes could be used easily as shapes; poorly defined classes, not so much
arnaud: I encourage people to make proposals, we can still leave this issue as umbrella for this question
<Arnaud> trackbot, end meeting