18:00:08 RRSAgent has joined #shapes 18:00:08 logging to http://www.w3.org/2016/06/09-shapes-irc 18:00:10 RRSAgent, make logs rdf-data-shapes 18:00:10 Zakim has joined #shapes 18:00:12 Zakim, this will be SHAPES 18:00:12 ok, trackbot 18:00:13 Meeting: RDF Data Shapes Working Group Teleconference 18:00:13 Date: 09 June 2016 18:00:21 agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.06.09 18:00:25 chair: Arnaud 18:01:41 marqh has joined #shapes 18:01:43 kcoyle has joined #shapes 18:02:36 Dimitris has joined #shapes 18:02:46 present+ 18:03:09 present+ 18:04:00 present+ 18:04:06 hknublau has joined #shapes 18:04:58 present+ 18:05:03 present+ 18:05:09 but i'm lacking a webex url 18:05:14 present+ 18:05:25 sorry for the confusion, is there a meeting number i can connect to please? 18:05:39 you mean, phone #? 18:05:53 jamsden has joined #shapes 18:05:53 no, just a webex url or meeting id 18:05:56 1-617-324-0000 18:05:59 present+ 18:06:23 Access code/Meeting number: 646 464 360 18:06:44 got it, ty 18:11:31 scribe: marqh topic: Admin 18:12:32 upcoming member, observing: pano 18:13:16 pano: work for Taxonic, for a couple of years: consultancy on linked data and semantic web 18:13:21 ... clients mostly public sector 18:13:54 ... working on projects with Dutch agency, maintain key registries in teh nederlands 18:14:25 ... transforming geographic data sets to linked data for sharing 18:14:38 ... RDF data may be used as source data for legislative systems 18:14:58 ... using shapes/shacl for the data model; targeting the shacl core for the current pilot project 18:15:26 ... we see shacl having various applications in many areas 18:15:35 ... keen to see shacl succeed 18:16:08 minutes of last meeting 18:16:10 PROPOSED: Approve minutes of the 2 June 2016 Telecon: http://www.w3.org/2016/06/02-shapes-minutes.html 18:16:13 Proposal: approve minute 18:16:49 some of the minutes are filled in from after the meeting by Arnaud 18:16:51 kudos for Arnaud's improv 18:17:33 please check the attribution of statements as part of approving the minutes 18:17:37 RESOLVED: Approve minutes of the 2 June 2016 Telecon: http://www.w3.org/2016/06/02-shapes-minutes.html 18:18:56 Arnaud: status check, charter. It is June, summer is coming and things will slow down. Most working groups are chartered for 2 years. This group has more time, more than 2 1/2 years 18:19:19 ... it is common for working groups to run out of time and have ~6 month extensions 18:19:30 ... this working group is unlikely to get such an extension 18:20:31 ... there is an official process to get such an extension, which may be hard for this group to get through. I want to bring to people's attention that we have 1 year left, until June next year. Time flies, so we need to keep in mind this aspect 18:21:09 pfps has joined #shapes 18:21:27 ... We have done a good job with use cases and requirements, and we have been focused on the shacl document, the timetable has not been well followed. Progress towards the end goal is ok 18:21:40 ... we require the test suite, which is some way behind 18:21:57 ... we should be looking at getting the recommendation by the end of the year 18:22:21 ... we require 2 implementations 18:22:55 ... time wise, I think that we should aim to have the bulk of the spec finished by the end of the year 18:23:27 ... the nature of the issues we have is that there are a lot and that some of them are major, which can have significant implications for the spec 18:23:42 ... we need to solve some of the core issues so that we can focus on cases 18:23:51 ... the core syntax and the reference model are crucial 18:24:20 ... I would like to remind everyone of this fact; you need to consider this time scale along side your strongly felt views 18:24:55 ... if at all possible, for the sake of making progress, we need to resolve key issues 18:25:15 ... there is the primer, the user friendly syntax, the relation to shex 18:25:40 ... i want to highlight the perspective, an extension is unlikely 18:26:36 topic: ISSUE-131 18:26:36 issue-131 -- The definition of sh:hasShape has errors and holes -- open 18:26:36 http://www.w3.org/2014/data-shapes/track/issues/131 18:26:51 arnaud: is this a problem which still needs to be fixed 18:26:57 pfps: yes 18:27:03 arnaud: what is the problem 18:27:20 pfps: we have never had a useable approach for sh:hasShape 18:27:59 arnaud: we don't have sh:hasShape any more, we have the function but not this part 18:28:08 ... when i looked, we don't have that any more 18:28:19 pfps: we certainly do have this still 18:28:39 ... recursion is error is no longer there 18:28:52 .. sh:hasShape is in the extension, the extension depends on it 18:29:15 ... this is a central part of shacl, it is the central part of the extension 18:29:53 arnaud: what is being done about this? is this a gap in the spec? not properly defined? 18:30:39 There are even controversies over the intuitive definition of sh:hasShape having to do whether it affects other variables with the same name. 18:30:40 http://w3c.github.io/data-shapes/shacl/#hasShape 18:30:54 hknublau: i'm not sure what problems need to be fixed. There are issuees with recursion: there are mistakes, structures are disabled. This needs to be changed. Once we do that, the hasShape is required again 18:31:22 That section of the spec has a completely broken notion of how SPARQL works. 18:31:42 Arnaud: i wanted to know if this is still relevant. pfps is suggesting we don't need this. hknublau suggests this is still required 18:31:51 arnaud: do we have an open issue on recursion? 18:32:07 In particular, variables in basic graph patterns are never evaluated, so they are not affected at all. 18:32:37 this issue needs to stay open 18:32:38 let's try and close issue 22 next week 18:33:06 There are at least three different options as to how sh:hasShape could work and there are noticeable differences in SHACL behaviour among the three. 18:33:25 topic: ISSUE-41 18:33:25 issue-41 -- Using property paths to refer to values/types? -- open 18:33:25 http://www.w3.org/2014/data-shapes/track/issues/41 18:33:51 Arnaud: we first decided to close this, but then recently it was suggested that this is not so hard and is useful 18:34:43 ... so it could be included, so we reopened it 18:35:02 ty simonstey 18:35:34 PROPOSED: Close ISSUE-41, adding property paths to SHACL 18:35:44 +1 18:35:47 q+ 18:35:51 ack hknublau 18:36:14 hknublau: some more details are needed; some are incremental, some are disruptive 18:36:45 ... for example replacing inverseProperty. we should aim to bring these in without damaging the current syntax 18:37:17 q+ 18:37:17 Arnaud: we cannot close the issue, await a concrete proposal, and then try to close the issue 18:37:55 ack Dimitris 18:38:45 https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0070.html or https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0004.html for possible solutions 18:38:45 Dimitris: we should fix some other issues before we see how property paths would impact the syntax 18:39:05 *solution proposals 18:39:13 q+ 18:39:18 Arnaud: hknublau prompted me to follow up on this to assist the syntax 18:39:25 ack hknublau 18:41:14 hknublau: this is related to issue-139 for 2 reasons. 1 once we have property paths, we could introduce property path validators, where the path is a placeholder; this would allow us to simplify sparql queries. We could provide this without user facing syntax, but we would be throwing out something useful. 2 discussion about whether any contratint can be applied anywhere. Paths would add a new case to our 18:41:20 considerations, before we can agree coverage of cases for constraints. 18:41:59 Arnaud: i can revise the proposal, to say 'we agree to add property paths'. then someone takes an action to make a proposal 18:42:16 q+ 18:42:17 ... I want us to agree that this is the path we want to take before the effort on the proposal is put in 18:42:23 ack hknublau 18:42:31 I am in favour of the idea of property paths 18:42:51 https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0004.html 18:43:00 hknublau: I believe it would be useful for this feedback to be gathered. In my email, I suggested a direction; the discussions on how to call things are required. 18:43:45 q+ 18:43:54 hknublau: in email #4, looking at the ttl snippet: the idea is to introduce a new property, inversePath, or pathConstraint or somesuch 18:44:23 ... it can have hasValue, maxCount etc. It wouldn't have a predicate, it would point at a path expression 18:44:55 I'm not in favour of numbered magic properties, e.g., sh:path1, sh:path2, ... 18:45:17 ... each list item would be one part of the sequence path. I have used blank nodes with properties like sequence path. The goal is to cover everything that is possible in sparql1.1 enabling a syntactic mapping to the sparql 1.1 syntax 18:45:30 I would prefer to use a property path string 18:45:31 ... we can then state that the semantics are equivalent to sparql 1.1 18:45:47 ack Dimitris 18:45:53 clear! 18:46:22 q+ 18:46:23 Dimitris: defining a property path is needed 18:46:29 I wonder how these bits of RDF syntax get turned into things that can go into the SPARQL code that implements constraint components. 18:47:25 pfps: propertyPaths I find useful; in my implementation they were easy to do. The problem is that hard wired into the sparql specification is a particular way to implement constraint components. 18:47:35 ack hknublau 18:47:38 ... something would have to be done to get property paths to work in line with sparql 18:48:25 hknublau: in response to Dimitris: I would be against the string based syntax. one issue is that the prefix discussion will show up again, requiring full uris. more importantly, we lose the ability to query that 18:49:00 ... an object oriented approach is preferred. I would prefer the use of rdf triples. also for non sparql related implementations 18:49:18 marqh: i agree with hknublau's view here 18:50:31 PROPOSED: add property paths to SHACL, using Holger's proposal as a starting point https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0004.html 18:50:33 -1 as the syntax of property paths in this proposal is horrible 18:50:45 q+ 18:51:05 +q 18:51:24 If the magic numbered properties were turned into lists I would be supportive 18:51:43 ack jamsden 18:51:46 a simpler approach with list like Peter and supporting very simple paths (forward / inverse) would be better 18:51:48 ok, thanks for the explanation 18:52:05 jamsden: i was wondering what requirement and use case is being satisfied by this? do we have a reference or is this a nice to have? 18:52:23 not sure if we need * + 18:52:55 jamsden: we have a set of use cases and requirements that we have agreed to. Is this in? is this a new requirement? 18:53:03 ... i don't know the answers to these 18:53:25 ack simonstey 18:53:33 https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0070.html 18:53:48 simonstey: one year ago, I was asked the same thing, to provide use cases. there are 2 use cases that relate to this, #27 and #32 18:54:29 ... this is about expressing relationships between values of multiple properties. There is partial support by other means, but it is not fully supported. This was the motivation 18:55:25 ... regarding the proposal from hknublau, which is related to spin's triple pass, is rather verbose. I was wondering whether teh javascript engine angle would need this capability 18:56:17 ... i don't see that as that big a problem. the simple approach with lists, I am more in favour of, over the verbose way to state the property path; a native sparql query may be more readable than this 18:56:49 Arnaud: pfps: when you object to the syntax, would you prefer string based syntax or a different approach 18:57:12 pfps: replacing the magic numbers is key, we need a solution which is not a step backwards 18:58:04 q+ 18:58:13 ack hknublau 18:58:21 Arnaud: I don't know where this leaves us. Are we addressing property paths with a different syntax: who will propose the syntax 18:58:52 hknublau: would it make sense to ask around? could we switch to rdf list syntax? this could be a simple alteration 18:58:56 ( ex:parent ex:parent ) 18:59:06 +1 for rdf list syntax from my p.o.v. 18:59:16 I'm fine with this kind of syntax. 18:59:30 I am fine with this approach as well 18:59:36 ( [ sh:inversePath ex:parent ] ex:pparent ) 19:00:02 hknublau: would this accellerate agreement here 19:00:14 +1 list 19:00:29 PROPOSED: add property paths to SHACL, using an rdf list based syntax 19:00:35 +1 19:00:44 +1 19:00:45 +1 19:00:46 +1 19:00:54 +0.9 19:00:57 +0Ç 19:01:00 0 19:01:22 0 19:01:25 :) 19:01:52 RESOLVED: add property paths to SHACL, using an rdf list based syntax 19:03:16 topic: ISSUE-139 19:03:16 issue-139 -- Can all constraint properties be applied in all scenarios? -- open 19:03:16 http://www.w3.org/2014/data-shapes/track/issues/139 19:03:24 q+ 19:03:38 ack Dimitris 19:04:29 Dimitris: i like pfps's ideas, I have proposed a hybrid solution, keeping some of the original design. if we can avoid the boiler plate code, that is better 19:05:12 ... the definitions of an override for an event, this would be good and could cover pfps's concern 19:06:18 Arnaud: background: we have some irregularities in the syntax; we could make the syntax more uniform and benefit users. on the other side, such generalisation means that people can write things which make no sense more easily 19:06:54 ... the counter, that implementing the general syntax once, has raised; the mailing list has had numerous discussions on both perspectives 19:07:50 ... straw poll last week supported more time on this. hknublau has suggested that this is a backwards step 19:08:14 https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0051.html 19:08:15 ? 19:08:37 q+ 19:08:41 ack pfps 19:09:24 pfps: as far as i can see, this propsal is about implementation, not syntax. i don't see that this is much of an advance, it adds even more complexity, but it allows much more hand optimisation 19:10:33 ... whether you view the ability to hand optimise the queries as positive is a separate matter. I don't think the spec should aim for hand optimisation. The spec should write general sparql that implementations, compilers, should do the work 19:11:33 Dimitris: the other part is similar to what pfps proposed. the first part is about the context, the second is about implementation 19:12:15 pfps: it's not clear what is meant by 'the other part' 19:13:13 i am also unable to hear Dimitris effectively 19:13:30 perhaps you could provide context here Dimitris? 19:14:02 Arnaud: so, do we end up with a generalised syntax. i am not sure what this proposal means for the syntax 19:14:34 Dimitris: there is 1 sparql query for each context. we have only one interpretation but still use the context 19:15:10 Arnaud: hknublau does this proposal change your objection 19:15:51 hknublau: firstly, should we delete context? i am strongly opposed to this; i need this feature, as do many others. 19:15:56 This depends on what "supported contexts" means. Does it mean that all constraint components are acceptable in for all kinds of constraints? Or does it just mean that there is a single implementation for those kinds of constraints that are supported for each constraint component. 19:15:58 q+ 19:16:16 ... the other aspect is about a single validator. if i can see a solution which works, i am open, but I have not seen it 19:16:54 ... there are cases where the situations are not that simple, with complicated sparql scenarios. even simple cases like asymmetric properties and unique value. expressing this generically is very hard 19:17:34 ... i am against this proposed simplification, if it stops us meeting particular use cases. we need a syntax for generalised sparql first 19:17:49 ack pfps 19:17:52 ... if someone can show how this would look, we can vote; until then we can't make a decision. 19:18:35 pfps: no one is arguing to get rid of context. the example of a tool to look at a graph still has all the information that it needs. I have shared a message that this is not the case 19:19:24 ... secondly, it is possible to write a constraint component that is completely different from any other component. Numerous examples are possible, should we allow that? 19:20:15 ... i think there is too much flexibility. every constaint can interpret the property differently. every constraint component gets to do its own thing with a property 19:20:47 ... to show that this is not a viable solution, we need to see components which cannot be done this way 19:21:13 q+ 19:21:22 Arnaud: interesting, so as sparql can do whatever it wants, we can claim that there is specific behaviour which is not sensible 19:21:28 ack hknublau 19:22:05 hknublau: currently, the design is that the main difference between property constrains and node constratins is that property constraints take a node value; which seems fine, as long as we can narrow down the context 19:22:34 what if we removed node constraints? that would solve many issues 19:22:36 ... for asymmetric property and unique value, it is fine to access the predicate. I don't want to create artifical limitations 19:23:20 ... pfps: in one of the emails, you suggested that we can get rid of context; if I misunderstood and we can keep context then that is all right 19:24:06 pfps: there is a vast difference between getting rid of all notions of context, and removing the sh:context which specifies which kind of contexts a constraint component can be used in 19:24:18 q+ 19:25:04 ... checker for sparql needs this. the boiler plate has to know what is going on, that is the context. the only thing I am advocating is that the indication that a particular constraint component is for particular kinds of constraint 19:25:11 ack hknublau 19:26:06 q+ 19:26:08 hknublau: what you are saying is correct for shapes graphs. you can find out the context at run time. The problem is input tools, where people edit things on input. when someone publishes a new constraint component, there is a need to define which context this is applied to 19:26:12 ack pfps 19:26:47 pfps: that's not correct. any style checker is going to need to know things about extensions. That doesn't mean that that property needs to be baked into the language 19:26:50 q+ 19:26:56 ack hknublau 19:27:08 pfps: there is no need to pollute the shacl namespace to make these checkers work better 19:27:49 hknublau: leaving things to custom namespaces is not what the standards are about. SPIN is like this, it is not useful enough as it is not a w3 standard. 19:28:13 q+ 19:28:33 pfps: at the end of june, I will no longer be in the working group Arnaud: unfortunately Nuance is discontinuing its membership so Peter will no longer be able to participate in the WG 19:28:57 can't he stay as invited expert? 19:28:57 ack hknublau 19:29:32 hknublau: a way forward that I would appreciate, as I would like to see a single syntax. I want to see a proper proposal. using the boiler plate code in all scenarios is not going to fly 19:30:00 ... someone needs to write the details down. it is not so easy. that is a step forward, if it could show up next week we can continue discussing it 19:30:11 I thought that the initial challenge was to just have single-implementation code for each core constraint component. I'm willing to do that. 19:30:50 Arnaud: i want to come up with a possible compromise, but this is beyond my help; i don't know how to make progress 19:31:09 Arnaud: we are out of time, the discussion will carry on on the mailing list 19:31:13 di nada :) 19:31:25 trackbot, end meeting 19:31:25 Zakim, list attendees 19:31:25 As of this point the attendees have been simonstey, Arnaud, Dimitris, marqh, hknublau, kcoyle, pano, pfps, ericP, jamsden 19:31:33 RRSAgent, please draft minutes 19:31:33 I have made the request to generate http://www.w3.org/2016/06/09-shapes-minutes.html trackbot 19:31:34 RRSAgent, bye 19:31:34 I see no action items