See also: IRC log
but i'm lacking a webex url
sorry for the confusion, is there a meeting number i can connect to please?
<Arnaud> you mean, phone #?
no, just a webex url or meeting id
<Arnaud> 1-617-324-0000
<Arnaud> Access code/Meeting number: 646 464 360
got it, ty
<Arnaud> scribe: marqh
upcoming member, observing: pano
pano: work for Taxonic, for a couple of years: consultancy on linked data and semantic web
... clients mostly public sector
... working on projects with Dutch agency, maintain key registries in teh nederlands
... transforming geographic data sets to linked data for sharing
... RDF data may be used as source data for legislative systems
... using shapes/shacl for the data model; targeting the shacl core for the current pilot project
... we see shacl having various applications in many areas
... keen to see shacl succeed
minutes of last meeting
<Arnaud> PROPOSED: Approve minutes of the 2 June 2016 Telecon: http://www.w3.org/2016/06/02-shapes-minutes.html
Proposal: approve minute
some of the minutes are filled in from after the meeting by Arnaud
<ericP> kudos for Arnaud's improv
please check the attribution of statements as part of approving the minutes
RESOLUTION: Approve minutes of the 2 June 2016 Telecon: http://www.w3.org/2016/06/02-shapes-minutes.html
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
... it is common for working groups to run out of time and have ~6 month extensions
... this working group is unlikely to get such an extension
... 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
... 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
... we require the test suite, which is some way behind
... we should be looking at getting the recommendation by the end of the year
... we require 2 implementations
... time wise, I think that we should aim to have the bulk of the spec finished by the end of the year
... 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
... we need to solve some of the core issues so that we can focus on cases
... the core syntax and the reference model are crucial
... I would like to remind everyone of this fact; you need to consider this time scale along side your strongly felt views
... if at all possible, for the sake of making progress, we need to resolve key issues
... there is the primer, the user friendly syntax, the relation to shex
... i want to highlight the perspective, an extension is unlikely
<trackbot> issue-131 -- The definition of sh:hasShape has errors and holes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/131
arnaud: is this a problem which still needs to be fixed
pfps: yes
arnaud: what is the problem
pfps: we have never had a useable approach for sh:hasShape
arnaud: we don't have sh:hasShape any more, we have the function but not this part
... when i looked, we don't have that any more
pfps: we certainly do have this still
... recursion is error is no longer there
... sh:hasShape is in the extension, the extension depends on it
... this is a central part of shacl, it is the central part of the extension
arnaud: what is being done about this? is this a gap in the spec? not properly defined?
<pfps> There are even controversies over the intuitive definition of sh:hasShape having to do whether it affects other variables with the same name.
<Arnaud> http://w3c.github.io/data-shapes/shacl/#hasShape
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
<pfps> That section of the spec has a completely broken notion of how SPARQL works.
Arnaud: i wanted to know if this is still relevant. pfps is suggesting we don't need this. hknublau suggests this is still required
... do we have an open issue on recursion?
<pfps> In particular, variables in basic graph patterns are never evaluated, so they are not affected at all.
this issue needs to stay open
<Dimitris> let's try and close issue 22 next week
<pfps> 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.
<trackbot> issue-41 -- Using property paths to refer to values/types? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/41
Arnaud: we first decided to close this, but then recently it was suggested that this is not so hard and is useful
... so it could be included, so we reopened it
ty simonstey
<Arnaud> PROPOSED: Close ISSUE-41, adding property paths to SHACL
<simonstey> +1
hknublau: some more details are needed; some are incremental, some are disruptive
... for example replacing inverseProperty. we should aim to bring these in without damaging the current syntax
Arnaud: we cannot close the issue, await a concrete proposal, and then try to close the issue
<simonstey> 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
Dimitris: we should fix some other issues before we see how property paths would impact the syntax
<simonstey> *solution proposals
Arnaud: hknublau prompted me to follow up on this to assist the syntax
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
considerations, before we can agree coverage of cases for constraints.
Arnaud: i can revise the proposal, to say 'we agree to add property paths'. then someone takes an action to make a proposal
... I want us to agree that this is the path we want to take before the effort on the proposal is put in
<Dimitris> I am in favour of the idea of property paths
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0004.html
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.
... in email #4, looking at the ttl snippet: the idea is to introduce a new property, inversePath, or pathConstraint or somesuch
... it can have hasValue, maxCount etc. It wouldn't have a predicate, it would point at a path expression
<pfps> I'm not in favour of numbered magic properties, e.g., sh:path1, sh:path2, ...
hknublau: 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
<Dimitris> I would prefer to use a property path string
hknublau: we can then state that the semantics are equivalent to sparql 1.1
<pano> clear!
Dimitris: defining a property path is needed
<pfps> I wonder how these bits of RDF syntax get turned into things that can go into the SPARQL code that implements constraint components.
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.
... something would have to be done to get property paths to work in line with sparql
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
... an object oriented approach is preferred. I would prefer the use of rdf triples. also for non sparql related implementations
marqh: i agree with hknublau's view here
<Arnaud> 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
<pfps> -1 as the syntax of property paths in this proposal is horrible
<simonstey> +q
<pfps> If the magic numbered properties were turned into lists I would be supportive
<Dimitris> a simpler approach with list like Peter and supporting very simple paths (forward / inverse) would be better
<pano> ok, thanks for the explanation
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?
<Dimitris> not sure if we need * +
jamsden: we have a set of use cases and requirements that we have agreed to. Is this in? is this a new requirement?
... i don't know the answers to these
<simonstey> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0070.html
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
... 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
... 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
... 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
Arnaud: pfps: when you object to the syntax, would you prefer string based syntax or a different approach
pfps: replacing the magic numbers is key, we need a solution which is not a step backwards
Arnaud: I don't know where this leaves us. Are we addressing property paths with a different syntax: who will propose the syntax
hknublau: would it make sense to ask around? could we switch to rdf list syntax? this could be a simple alteration
<hknublau> ( ex:parent ex:parent )
+1 for rdf list syntax from my p.o.v.
<pfps> I'm fine with this kind of syntax.
<Dimitris> I am fine with this approach as well
<hknublau> ( [ sh:inversePath ex:parent ] ex:pparent )
hknublau: would this accellerate agreement here
<simonstey> +1 list
<Arnaud> PROPOSED: add property paths to SHACL, using an rdf list based syntax
<hknublau> +1
<simonstey> +1
<Dimitris> +1
+1
<pfps> +0.9
<kcoyle> +0Ç
<ericP> 0
<jamsden> 0
<pano> :)
RESOLUTION: add property paths to SHACL, using an rdf list based syntax
<trackbot> issue-139 -- Can all constraint properties be applied in all scenarios? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/139
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
... the definitions of an override for an event, this would be good and could cover pfps's concern
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
... the counter, that implementing the general syntax once, has raised; the mailing list has had numerous discussions on both perspectives
... straw poll last week supported more time on this. hknublau has suggested that this is a backwards step
<simonstey> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0051.html
<simonstey> ?
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
... 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
Dimitris: the other part is similar to what pfps proposed. the first part is about the context, the second is about implementation
pfps: it's not clear what is meant by 'the other part'
i am also unable to hear Dimitris effectively
perhaps you could provide context here Dimitris?
Arnaud: so, do we end up with a generalised syntax. i am not sure what this proposal means for the syntax
Dimitris: there is 1 sparql query for each context. we have only one interpretation but still use the context
Arnaud: hknublau does this proposal change your objection
hknublau: firstly, should we delete context? i am strongly opposed to this; i need this feature, as do many others.
<pfps> 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.
hknublau: 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
... 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
... i am against this proposed simplification, if it stops us meeting particular use cases. we need a syntax for generalised sparql first
... if someone can show how this would look, we can vote; until then we can't make a decision.
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
... 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?
... 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
... to show that this is not a viable solution, we need to see components which cannot be done this way
Arnaud: interesting, so as sparql can do whatever it wants, we can claim that there is specific behaviour which is not sensible
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
<Dimitris> what if we removed node constraints? that would solve many issues
hknublau: for asymmetric property and unique value, it is fine to access the predicate. I don't want to create artifical limitations
... 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
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
... 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
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
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
... there is no need to pollute the shacl namespace to make these checkers work better
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.
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
<Dimitris> can't he stay as invited expert?
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
... 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
<pfps> I thought that the initial challenge was to just have single-implementation code for each core constraint component. I'm willing to do that.
Arnaud: i want to come up with a possible compromise, but this is beyond my help; i don't know how to make progress
... we are out of time, the discussion will carry on on the mailing list
di nada :)
<Arnaud> trackbot, end meeting