13:46:36 <RRSAgent> RRSAgent has joined #shapes
13:46:36 <RRSAgent> logging to http://www.w3.org/2015/12/17-shapes-irc
13:46:38 <trackbot> RRSAgent, make logs rdf-data-shapes
13:46:38 <Zakim> Zakim has joined #shapes
13:46:40 <trackbot> Zakim, this will be SHAPES
13:46:40 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:46:41 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
13:46:41 <trackbot> Date: 17 December 2015
13:48:09 <hknublau> present+
13:49:01 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/F2F5#Day_3_-_Thursday_Dec_17
13:49:04 <Arnaud> chair: Arnaud
13:50:59 <simonstey> simonstey has joined #shapes
13:54:37 <Dimitris> Dimitris has joined #shapes
13:55:31 <Arnaud> the teleconference bridge is now open
13:55:41 <Arnaud> present+
13:56:23 <Dimitris> present+
13:56:26 <simonstey> hm.. new access code?
13:56:53 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/F2F5#Remote_Participation
13:57:11 <simonstey> now I hear some music playing
13:57:20 <simonstey> nice though ;)
13:57:27 <arthurryman> arthurryman has joined #shapes
13:57:33 <Arnaud> hmm, you must have dialed the wrong number
13:57:55 <simonstey> ah now
13:58:10 <aryman> present+ aryman
13:58:20 <simonstey> present+ simonstey
13:58:57 <ericP> the dial-in codes are short; it may be a dense matrix
13:59:53 <simonstey> I guess I typed it in too quickly
14:02:57 <simonstey> scribe: simonstey
14:03:06 <pfps> pfps has joined #shapes
14:03:33 <simonstey> Arnaud: 2 main agenda items, ShEx & testsuite
<simonstey> topic: SHACL & ShEx
14:04:08 <simonstey> Arnaud: when it comes to shex, you all know what shex is about
14:05:01 <simonstey> ... we started the group with 3 proposals; we decided to go with holger's approach but wanted to use shex as our high-level language
14:05:13 <ericP> present+
14:06:05 <simonstey> ... shex is continuously progressing; shex guys feel not be very welcome in the group and even might withdraw from the group
14:06:39 <simonstey> ... I wish we would have more collaboration on this
14:07:08 <iovka> present+
14:07:42 <simonstey> ... the idea to today is to get more visibility on what's currently going on with shex
14:08:20 <simonstey> ... ericP will tell us whether we could still use shex; although we certainly would have to find compromises on both sides
14:08:48 <simonstey> ... whenever semantics dont match, we have to decide which approach we should follow up on
14:09:40 <simonstey> ... I wanted to have more discussion on how shex relates to shacl
14:09:57 <simonstey> ... i.e. if and how we can use shex on top of shacl
14:10:42 <aryman> q+
14:10:50 <Arnaud> ack aryman
14:11:00 <simonstey> ... if it turns out that there is no common ground between shex&shacl, then that's still useful info
14:12:05 <simonstey> aryman: I would like to have eric to pick an example using some actual data and show constraints that can be expressed in shex but not (or at least not very pretty) in shacl
14:13:24 <simonstey> Arnaud: I wanted to have a list of things that are actually blocking the use of shex on top of shacl
14:13:59 <ericP> http://www.w3.org/2015/Talks/1217-shexshacl-egp/
14:14:01 <simonstey> ... I hope ericP's presentation can help us identifying those gaps
14:14:08 <simonstey> ShExC grammar: http://www.w3.org/2005/01/yacker/uploads/ShEx2?lang=perl&markup=html#productions ShExJ (JSON) grammar: http://shex.io/primer/ShExJ#schema tests: https://github.com/shexSpec/shexTest/tree/master/validation
14:14:53 <simonstey> ericP: goal is to allow shacl to use shex as high-level syntax iff (almost) entire semantics are shared
14:15:24 <simonstey> ... if we only share parts of the semantics it's hard to argue any other use than transforming back and forth
14:16:16 <simonstey> ... big differences are: in shex you have the shape and shape expressions; in shacl you e.g. have ORs of entire shapes instead of shape expressions
14:16:26 <TallTed> TallTed has joined #shapes
14:17:24 <simonstey> ... shex defines shapes to be different from the actual shape expressions
14:18:23 <simonstey> ... value expressions are also handled differently
14:19:08 <simonstey> ... which all relates to what your grammar allows you to nest in what
14:20:02 <simonstey> ... shex also supports stems
14:20:18 <simonstey> ... the biggest difference is in the included middle constraints though
14:20:32 <simonstey> ... [2nd bullet point slide 5]
14:21:02 <Arnaud> http://shex.io/primer/#issue-1
14:21:42 <pfps> included middle seems a strange way to describe this feature of ShEx
14:21:43 <simonstey> ericP: a tester has some particular constraints, and a programmer has some constraints
14:22:06 <simonstey> ... we could write those constraints down by using QCR
14:22:55 <simonstey> aryman: what are the exact semantics here?
14:23:05 <simonstey> [in the example]
14:23:08 <simonstey> ericP: one of each
14:23:35 <simonstey> ... well we could write that down in shacl (although quite verbose)
14:23:52 <simonstey> ... but there are differences when someone is both a programmer and a tester
14:24:41 <simonstey> ... in shex it passes if someone is a tester and someone is a tester and a programmer
14:25:18 <simonstey> ... in shacl it raises an cardinality constraint violation
14:25:30 <simonstey> because there is one programmer but two tester
14:25:46 <simonstey> s/because there is one programmer but two tester/... because there is one programmer but two tester
14:26:36 <simonstey> Arnaud: 1) question: there is one person who has two roles
14:26:50 <simonstey> ... 2) question: there are two persons one of which has both roles
14:26:54 <simonstey> ericP:
14:28:29 <simonstey> [discussing example given in http://shex.io/primer/#issue-1 ]
14:29:23 <simonstey> ericP: we are not actually married to this semantics, but we can never know if such an example will show up (or not)
14:30:15 <kcoyle> q+
14:30:32 <simonstey> iovka: one can think of cases where you need the shex way of handling this and one might think of ways where shacl semantics are preferable
14:31:20 <simonstey> ... static analysis that two shapes are disjoint is very difficult
14:32:16 <simonstey> ... with simple computations you can find the stuff that's in the middle
14:33:39 <simonstey> ericP: we could e.g. say that if behavior differs we could define it as being undefined and implementers could decide which approach they want to follow (shex or shacl)
14:33:41 <kcoyle> q-
14:34:22 <aryman> q+
14:34:39 <pfps> is the "default" interpretation of ShEx shapes completely open ??
14:35:25 <simonstey> Arnaud: I think there is nothing that prevents one being programmer and tester at the same time, when looking at the example of issue 1
14:36:38 <simonstey> kcoyle: I dont really think that this is actually a deciding factor; what we are talking about now is whether we can directly translate shex to shacl
14:37:20 <simonstey> ... I'm also not sure whether there is enough justifaction to use shex as high-level syntax of shacl anyway
14:37:59 <simonstey> ... this particular decision should not be made by us but by the actual users
14:38:55 <pfps> I hadn't heard anything about ordering in ShEx before either
14:39:08 <simonstey> ... for example I just recently discovered that shex actually supports ordering
14:39:44 <Arnaud> ack aryman
14:39:54 <simonstey> ... we never had an actual high-level presentation of shex; just e.g. discussions on additive vs non-additive
14:40:55 <simonstey> aryman: [bringing up his partition strategy]
14:42:04 <simonstey> ericP: I wanted to have this on the top level; i.e. this being the default behavior
14:42:24 <simonstey> ... however we are not married with the partition approach
14:43:11 <simonstey> aryman: if we would adopt the sh:partition operator in shacl we would bring shex&shacl semantics closer together
14:43:44 <simonstey> ericP: yes my goal was to enumerate those points
14:43:50 <simonstey> ... the last one is filtershape
14:44:13 <simonstey> ... in shex we basically say: there is a grammar for traversing the graph
14:45:45 <simonstey> ... unfortunately, filtershape does not directly fit into the shex philosophy of executing constraints
14:45:59 <simonstey> s/executing/checking
14:47:09 <simonstey> you can have filtershapes also within constraints
14:47:13 <simonstey> rather than shapes
14:47:39 <simonstey> hknublau: a filtershape is narrowing the scope
14:47:50 <simonstey> ... but there is an open issue for that
14:49:36 <simonstey> q+
14:50:28 <simonstey> [discussing semantics of filtershape]
14:50:43 <Arnaud> ack simonstey
14:51:02 <Dimitris> http://www.w3.org/2014/data-shapes/track/issues/49
14:53:31 <pfps> a big problem I have throughout the ShEx discussion of bugs is that my assumptions about bug reporting are violated throughout.  A bug that has been reported multiple times is just as good a bug as a bug that has been reported only once.  However most of the ShEx shapes do not allow an arbitrary number of reportings.  In my view a better example is needed for ShEx
14:54:04 <simonstey> hknublau: in fact, scoping and filtering work differently from an implementation perspective
14:54:49 <pfps> the other problem is that it seems strange to use just one property for both reporting and reproducing
14:55:02 <simonstey> ericP: the other use of filter shape (example 8) is validating an optional property, i.e. a property doesnt have to be there but if it is it has to conform to some shape
14:55:53 <simonstey> ... I'm wondering if there are any other examples of filtershapes that could not be translated to shex
14:56:18 <simonstey> hknublau: that's not quite right.. example 8 doesnt have an optional property
14:56:30 <simonstey> aryman: it's actually an if .. then ..
14:57:41 <Labra> Labra has joined #shapes
14:57:49 <simonstey> [more discussion on semantics of example 8 in http://w3c.github.io/data-shapes/shacl/#filterShape]
14:59:32 <pfps> q+
14:59:32 <Labra> present+ labra
14:59:38 <simonstey> ericP: the question is, if we have a translation back and forth between shex&shacl, can shex serve as an high-level syntax for shacl or not?
14:59:39 <pfps> present+ pfps
15:01:33 <pfps> the question in my mind is just whether ShExC has syntactic constructs for most or all SHACL syntactic constructs, ignoring any semantic issues
15:02:22 <simonstey> ericP: I dont have any confidence that a construct e.g. using a disjunction in shex can actually be used to express e.g. example 8
15:02:32 <Arnaud> ack pfps
15:02:52 <simonstey> aryman: I would already be happy if we can find a translation of shex to shacl but not necessarily the other way roune
15:02:56 <simonstey> s/roune/round
15:03:47 <aryman> q+
15:04:33 <simonstey> Arnaud: I think the shex people would not be very happy to have their syntax hijacked with a different semantics
15:05:19 <simonstey> pfps: shex has been proposed as input to the wg so the wg could do what ever it wants with that
15:06:04 <simonstey> Arnaud: technically true, but from a diplomatic point of view that may not be a very clever decision
15:06:36 <simonstey> ... are you willing to give up your semantics for the sake of shacl using your syntax?
15:06:54 <simonstey> s/you/the shex guys
15:07:51 <simonstey> ericP: if you say "can we have the shex syntax and commas are ands" then the answer is no
15:08:44 <Arnaud> ack aryman
15:09:26 <simonstey> aryman: shex has its own syntax and rdf has its own syntax
15:09:34 <pfps> the funny thing about this is that the additive semantics was not part of ShEx initially
15:09:53 <simonstey> ... arguably writing rdf isnt very userfriendly
15:10:11 <simonstey> ... it seems to me that as long as we can translate shex into shacl we are fine
15:11:04 <pfps> if the major construct is different between ShExC and SHACL-in-RDF then I don't see any benefit
15:11:05 <pfps> q+
15:11:10 <simonstey> ... I don't think it's a conflict; only things that are not translateable or just in a very weirdly manner than we need to close that gap
15:11:24 <Arnaud> ack pfps
15:12:28 <simonstey> pfps: aryman suggestion is a non starter; suppose we have ShExC having the most prominent combining constructor being additive
15:12:37 <iovka> q+
15:12:44 <aryman> q+
15:12:45 <simonstey> ... and shacl in rdf, where that's conjunctive
15:12:54 <Arnaud> ack iovka
15:13:00 <simonstey> ... as a user I would be very confused
15:13:28 <simonstey> iovka: I dont see this being that problematic
15:13:32 <Arnaud> ack aryman
15:14:23 <simonstey> aryman: what peter says is true, however the main conflict occurs if we want to express more than one constraint on one property (and there is an included middle)
15:15:02 <pfps> ShEx and SHACL diverge even when there are no repeated properties - there are different stances on openness
15:20:13 <ericP> true
15:31:44 <Dimitris> Dimitris has left #shapes
15:31:49 <Dimitris> Dimitris has joined #shapes
15:33:56 <Arnaud> zakim, who's here?
15:33:56 <Zakim> Present: hknublau, Arnaud, Dimitris, aryman, simonstey, ericP, iovka, labra, pfps
15:33:58 <Zakim> On IRC I see Dimitris, Labra, TallTed, pfps, aryman, simonstey, Zakim, RRSAgent, kcoyle, iovka, hknublau, Arnaud, bjonnh, ericP, trackbot
15:34:09 <aryman> present+ aryman
15:34:25 <iovka> present+ iovka
15:34:40 <iovka> (i have to leave in 40 min)
15:34:50 <aryman> scribe: aryman
15:35:27 <aryman> Topic: ShEx and SHACL Relation Continued
15:36:38 <kcoyle> q+
15:36:44 <aryman> Arnaud: Let's be less divisive
15:37:08 <Arnaud> ack kcoyle
15:37:17 <aryman> Arnaud: Let's be more collaborative
15:38:40 <aryman> kcoyle: Rather than unify ShEx and SHACL, which have some major mismatches, or should we simply define our own compact syntax?
15:39:16 <aryman> s/ or//
15:40:06 <aryman> Arnaud: It is desirable to unify the community. Failing that we can define a compact syntax for SHACL.
15:40:17 <iovka> q+
15:40:38 <Arnaud> ack iovka
15:41:49 <pfps> my argument was supposed to be along the lines that karen made - that the major differences mean that using ShExC with ShEx semantics as the user-friendly syntax for SHACL creates something that doesn't work
15:42:18 <aryman> iovka: From a technical point of view we can translate many ShEx documents to SHACL. If we add a sh:partition operator to SHACL then we can translate more. We may also be able to staticallt detect when we can't translate.
15:42:41 <aryman> s/staticallt/statically/
15:43:16 <aryman> Arnaud: The ShEx community also brings valuable use cases from Mayo clinic. See ISSUE-92.
15:43:49 <kcoyle> q+
15:44:44 <aryman> ericP: The ShEx community can work from a distance on the translation.
15:44:47 <aryman> q+
15:44:57 <Arnaud> ack kcoyle
15:45:06 <aryman> Arnaud: the danger is lack of visibility to the WG
15:45:56 <aryman> kcoyle: Are still working on SHACL or is it ShEx? The work must be integrated into the WG specs.
15:47:09 <aryman> Arnaud: We should have a document that specifies the compact syntax and the mapping to RDF SHACL.
15:47:46 <simonstey> deliverable: OPTIONAL - Compact, human-readable, non-RDF syntax for expressing constraints on RDF graph patterns (aka shapes), suitable for the use cases determined by the group.
15:48:08 <aryman> kcoyle: Disagree that we should have two syntaxes. Why do we need two syntaxes?
15:48:47 <aryman> Arnaud: The charter specifies both syntaxes.
15:48:51 <Arnaud> ack aryman
15:50:56 <kcoyle> q+
15:51:32 <Arnaud> ack kcoyle
15:51:34 <iovka> aryman: there are technical reasons why we could want both rdf based syntax and compact syntax
15:51:47 <iovka> aryman: for instance, rdf has different syntaxes
15:52:53 <iovka> aryman: the constraint language is not bound to the syntax(es)
15:53:20 <aryman> kcoyle: Do they have to be exactly the same (in design philosophy)? Otherwise this would confuse users who moved between the two.
15:54:21 <aryman> kcoyle: Is SHACL unchangeable?
15:55:01 <aryman> Arnaud: No. We should entertain any proposal that eliminates the differences.
15:57:15 <aryman> kcoyle: We should look at which approach reflects the majority of use cases and move to that.
15:57:29 <pfps> q+
15:57:33 <Arnaud> ack pfps
15:58:49 <aryman> pfps: Adding an additive construct to SHACL still does not unify the languages
15:59:22 <aryman> Arnaud: Let's list the main differences
15:59:33 <pfps> Another difference is the different kinds of closure and openness.
15:59:39 <aryman> 1) Additive vs Conjunctive
15:59:52 <aryman> 2) Open vs Closed
15:59:58 <pfps> I don't understand what aspect of ShEx is ordered
16:00:18 <kcoyle> Peter, I don't either, which is also why it surprised me
16:00:48 <aryman> Arnaud: What motivated ShEx to be additive
16:02:09 <aryman> ericP: originally ShEx used Resource Shape semantics (each property mentioned once). Then work with clinical data showed multiple uses of the same property, e.g. for different types of observations.
16:02:30 <pfps> The medical examples appear to me to all have no overlap between the shapes
16:02:32 <pfps> q+
16:02:39 <Arnaud> ack pfps
16:02:46 <aryman> Arnaud: Aren't these important use cases?
16:02:46 <hknublau> There is always SPARQL as a fallback.
16:04:01 <aryman> pfps: In clinical data, is the problem caused by poor RDF design?
16:05:15 <pfps> q+
16:05:18 <aryman> ericP: For example, blood pressure has two measurements (systolic and diastolic) which are distinguished by codes.
16:06:18 <aryman> ericP: SHACL can express this using qualified constraints but it is very awkward.
16:06:49 <Arnaud> ack pfps
16:08:12 <aryman> pfps: There are less awkward ways to say that in OWL. The Issue example is somewhat contrived.
16:08:14 <iovka> q+
16:08:49 <Arnaud> ack iovka
16:09:01 <aryman> ericP: We are not married to the current partition semantics but haven't found a better way.
16:09:36 <aryman> iovka: In the blood pressure example but ShEx and SHACL have the same problem.
16:10:28 <pfps> q+
16:10:54 <Arnaud> ack pfps
16:11:01 <aryman> Arnaud: Are we victims of inertia and history?
16:11:29 <iovka> q+
16:11:37 <Arnaud> ack iovka
16:11:58 <aryman> pfps: The problem with the partitioning semantics is implementing partitioning
16:12:32 <pfps> I'm not saying that partitioning is impossible, just that it is not easy
16:12:35 <pfps> q+
16:12:39 <Arnaud> ack pfps
16:12:58 <aryman> iovka: Partitioning is only problematic with repeated properties. We have defined a "lookahead" algorithm that improves the performance of partitioning.
16:13:55 <aryman> pfps: Agree that the problem only occurs with repeated properties. The worst case is tough, but in practice we often do not get the worst case.
16:14:32 <iovka> q+
16:14:41 <Arnaud> ack iovka
16:14:42 <aryman> pfps: Still a major problem because we have little implementation experience.
16:15:49 <aryman> iovka: Agree that implementing partitioning is more difficult. We do have some experience and we can help programmers do this better.
16:16:39 <pfps> I think that Arthur's proposal for partition does not have the same implementation complexity
16:16:47 <aryman> Arnaud: Should additive be the default for repeated properties in SHACL.
16:16:52 <aryman> q+
16:17:12 <pfps> q+ unless Arthur handles my comment
16:17:20 <Arnaud> ack aryman
16:17:23 <pfps> q+
16:17:49 <iovka> aryman: it seems that pfps's main concern is complexity, this is also mine
16:17:55 <pfps> q-
16:18:18 <ericP> q+
16:18:20 <iovka> aryman: maybe you can reduce this in practice, but the proposal I made allows to test them in order and reduces the complexity
16:18:43 <iovka> s/test them/test them in order/
16:18:50 <pfps> q+
16:18:55 <Arnaud> ack ericP
16:19:51 <aryman> ericP: I am fine with that proposal ...
16:23:00 <aryman> ericP: the proposal would be to put terms use lists for ordering wherever we need it, and use the greedy algorithm for evaluation
16:23:05 <ericP> <S> a sh:Shape ; sh:expression ( [ a sh:PropertyConstraint .. ] [ ... ] )
16:23:36 <Arnaud> ack pfps
16:23:48 <pfps> Another option would be to have an exclusive partiion construct that is not ordered but fails if any value falls in more than one of the partitions.
16:24:15 <iovka> q+
16:24:16 <ericP> q+
16:24:23 <ericP> q-
16:24:27 <Arnaud> ack iovka
16:26:22 <iovka> q+
16:26:30 <Arnaud> ack iovka
16:26:33 <aryman> discussion about implicit negation
16:27:13 <aryman> iovka: can we proceed based on this proposal to add a partitioning construct to SHACL?
16:28:26 <aryman> Arnaud: good discussion, let's keep it open, encouraging, use mailing list to continue it
16:28:38 <ericP> +1
16:29:12 <aryman> refer to ISSUE-92 in emails on this topic
16:29:16 <aryman> +1
16:30:04 <aryman> q+
16:30:07 <iovka> +1
16:30:09 <Arnaud> ack aryman
16:30:53 <aryman> aryman: we should also add stemming to SHACL
16:31:19 <iovka> (have to leave, good morning/aftenoon/night to all)
16:31:28 <aryman> bye iovka
16:33:06 <Arnaud> break 30mn
16:59:10 <aryman> aryman has joined #shapes
17:01:09 <pfps> present+
17:06:11 <kcoyle> kcoyle has joined #shapes
17:09:23 <hknublau> scribe: hknublau
17:09:49 <hknublau> Topic: Test Suite
17:10:35 <hknublau> Arnaud: What is the status of converting/reusing the ShEx test cases?
17:10:55 <hknublau> ericP: I am encouraged by the discussion we just had
17:12:15 <hknublau> ... took care of 2 issues, including additive semantics, we have a couple of hundreds test cases
17:12:32 <hknublau> ... other tests are about syntax conversions (JSON etc)
17:13:14 <hknublau> ... 200 validation tests, 800 transformation tests
17:14:58 <hknublau> ... we still need to wait for the outcome of the alignment discussion
17:16:14 <pfps> as the major combining constructs in ShEx and SHACL are different, checking is needed to determine whether tests for one are appllicable to the other
17:16:26 <hknublau> ... (discussion of some details on how to translate tests)...
17:17:45 <hknublau> ... requires more investigation on how to proceed, but worth trying at least for a subset of the tests
17:18:39 <kcoyle> q+
17:18:41 <hknublau> Arnaud: I find it unfortunate that we have stalled on the test suite. Should not be limited to what ShEx people can provide.
17:19:11 <hknublau> ... Discussion and resolution of ISSUEs should lead to test cases.
17:19:51 <hknublau> ericP: Fastest path is to work on the ShEx integration, then we can look at Jose's automatic translator
17:20:37 <Arnaud> ack kcoyle
17:21:10 <hknublau> kcoyle: What format should the tests be?
17:21:45 <hknublau> ... someone in our group created a SHACL file (validated using TopBraid)
17:22:56 <ericP> https://github.com/shexSpec/shexTest/blob/master/validation/manifest.ttl
17:23:19 <ericP> https://github.com/shexSpec/shexTest/blob/master/validation/manifest.jsonld
17:23:49 <hknublau> hknublau: I do have some additional tests but not nearly enough, and they are in a slightly different format
17:27:10 <hknublau> Arnaud: is there a need to simplify the test case file format?
17:28:14 <hknublau> ericP: JSON-LD has some advantages, better tool reuse
17:29:25 <hknublau> hknublau: I am open to using both Turtle or JSON-LD, but they should be in RDF, not compact syntax
17:31:25 <hknublau> ericP: The existing format has some tool support from Greg Kellogg
17:33:25 <hknublau> hknublau: I'd be happy to contribute more tests once I have a breather. But too busy right now.
17:33:43 <hknublau> ... we have tool support in TopBraid now to create them easily, so I expect progress when I have time
17:34:03 <hknublau> ericP: Will help Karen's colleague with the format.
17:36:15 <hknublau> Arnaud: meta-comment that Face to Face meetings prevent dropping out
17:37:19 <hknublau> q+
17:37:35 <Arnaud> ack hknublau
17:38:24 <Arnaud> topic: ISSUE-23
17:41:30 <hknublau> hknublau: Summary of current situation with ISSUE-23
17:41:43 <hknublau> ... parallels with ShEx vs SHACL discussion
17:42:50 <hknublau> Arnaud: Holger dropped his sh:ShapeClass proposal, and presented a softer proposal
17:43:42 <hknublau> ... I presented this to the group, I sensed philosophical difference, I thought there was not much point in continuing
17:44:02 <hknublau> ... this forced a certain viewpoint on everyone
17:44:28 <hknublau> ... we had 2 extremes, and I thought we shouldn't have a religious debate
17:45:07 <hknublau> ... allow both views. Consequences are well-understood. We could highlight caveats in the spec.
17:46:01 <hknublau> ... vast majority was of opinion to forcing the separated worldview
17:46:35 <hknublau> ... Ted seems to be agreeing with Holger, but he is not present on the call
17:46:56 <hknublau> ... meanwhile Dimitris proposal came along, not fully understood yet.
17:47:15 <Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Dec/0032.html
17:48:18 <pfps> in my view this boils down to the stance on whether ex:node rdf:type ex:Shape is to be supported in SHACL
17:49:13 <pfps> q+
17:49:19 <Arnaud> ack pfps
17:49:44 <hknublau> pfps: Dimitris proposal is even worse than the previous one.
17:50:11 <hknublau> ... it has an explicit construct for the design pattern permitting a node is an instance of a shape
17:51:29 <pfps> in the folllowing data graph  ex:node rdf:type ex:Shape . ex:Shape rdf:type sh:ShapeClass.  the constraints on sh:Shape will be applied to ex:node
17:52:56 <pfps> n the folllowing data graph  ex:node rdf:type ex:Shape . ex:Shape rdf:type sh:ClassShape.  the constraints on sh:Shape will be applied to ex:node
17:54:03 <pfps> In the folllowing data graph  ex:node rdf:type ex:Shape . ex:Shape rdf:type sh:ClassShape.  the constraints on ex:Shape will be applied to ex:node
17:55:02 <hknublau> hknublau: sh:ClassShape is just syntactic sugar abbreviating one triple
17:55:40 <hknublau> Dimitris: My approach drops the metaclass.
17:57:54 <pfps> The only difference at all between Dimitri's proposal and the current editors' draft is that sh:ShapeClass has changed to sh:ClassShape
17:57:58 <hknublau> hknublau: I am happy to downplay this, drop any examples etc in the spec
18:02:35 <hknublau> Dimitris: Now the ontologies are completely separated from the shape, and this gives users a way to reuse the same URI for classes
18:03:11 <hknublau> ... and it drops metaclasses, impacting inferencing and other complications.
18:05:25 <hknublau> ... what I like about this is that it makes it clear that this is about the class
18:06:14 <hknublau> pfps: the only change I see from before is that it saves the reflexive  sh:scopeClass triple
18:06:42 <hknublau> ... 3 approaches:
18:07:04 <hknublau> ... a) Classes and shapes must be disjoint, doing this is illegal
18:07:34 <hknublau> ... b) Special kind of class that is also a shape that triggers validation
18:08:08 <hknublau> ... c) Be agnostic, we don't say that shapes can be classes
18:09:50 <hknublau> ... d) There could also be a design structure that makes something both a shape and a class then this means validation
18:12:15 <pfps> The fourth approach would be to have nodes that are in the data graph and that are also shapes in the shapes graph trigger a kind of nodeshape validation
18:13:26 <hknublau> hknublau: I believe a main issue remains the difference between modeling (in Peters terms: real world entities) and data modeling/constraining.
18:13:34 <Arnaud> foaf:Person a rdfs:Class. x:PersonShape a sh:Shape; sh:scopeClass foaf:Person. ex:Alice a foaf:Person .
18:14:28 <Arnaud> foaf:Person a rdfs:Class, sh:Shape; sh:scopeClass foaf:Person. ex:Alice a foaf:Person .
18:16:08 <Dimitris> foaf:Person a rdfs:Class, sh:ClassShape. ex:Alice a foaf:Person .
18:17:27 <hknublau> hknublau: Important that the triples above are typically split across two graphs
18:24:15 <pfps> I sure hope that I am not just an record in a document on the web
18:24:56 <kcoyle> at this moment, i'd rather be that
18:29:21 <pfps> the ShEx workarounds require use of SPARQL, which appear to me to be quite complex
18:29:50 <pfps> the workaround here involves a single triple, which appears to me to be very much simpler
18:31:07 <hknublau> that's your personal opinion, but based on our experience this won't fly at all and will sink the whole approach.
18:31:21 <hknublau> you can have your personal opinion, but I want to ask the market to decide, not us.
18:31:43 <hknublau> We are in the end just a handful of people.
18:33:01 <hknublau> (Sorry I could not write the remaining discussion of this session. It was largely about discussing whether this triple shortcut is relevant or not).
18:34:14 <hknublau> My honest impression right now is that people are intentionally preventing this trial on the market, for no technical reason.
18:34:40 <Arnaud> you're free to try it on the market with your products
18:34:49 <Arnaud> that's what companies do all the time
18:43:40 <hknublau> We already have that situation with SPIN, but people want W3C standards, and furthermore we need database vendors to support this too.
18:44:14 <hknublau> Exactly the same applies to ShEx. We could ignore them too.
18:44:57 <Arnaud> almost
18:46:59 <kcoyle> "7 participants on the call" -- haven't heard from most of us?
18:47:46 <Arnaud> zakim, who's present?
18:47:46 <Zakim> I don't understand your question, Arnaud.
18:47:53 <Arnaud> zakim, who's here?
18:47:53 <Zakim> Present: hknublau, Arnaud, Dimitris, aryman, simonstey, ericP, iovka, labra, pfps
18:47:56 <Zakim> On IRC I see kcoyle, Dimitris, Labra, TallTed, pfps, Zakim, RRSAgent, hknublau, Arnaud, bjonnh, ericP, trackbot
18:48:16 <Labra> * I'm here but I will have to leave in half an hour
18:48:21 <Arnaud> present+ kcoyle
18:49:09 <pfps> abstract syntax?
18:59:15 <kcoyle> scribe: kcoyle
18:59:35 <Labra> * I would like if someone could write what Peter said
18:59:55 <Labra> * It was surprising for me
18:59:59 <kcoyle> talking about question of revisiting decision to use shacl as basis
19:00:22 <kcoyle> pfps: main disagreement is over developing of a modeling language
19:01:50 <pfps> when the decision between SPIN and ShEx was made it was easy
19:02:02 <kcoyle> no meeting next week
19:02:14 <pfps> a decision now would be much harder, because ShEx has improved
19:02:31 <pfps> but that's not a good reason to revisit the decision
19:02:48 <kcoyle> nor the next (the 31st); next telecon will be on the 7th of January 2016
19:03:24 <pfps> a better reason is that SHACL may be changing
19:03:55 <kcoyle> Arnaud: have we covered all of the topics on our list for this meeting? seems so
19:04:20 <pfps> a major aspect of this change to me is whether SHACL is a modelling language (modelling in the sense of logic, not in the sense of data schemas)
19:04:30 <hsolbrig> hsolbrig has joined #shapes
19:05:11 <pfps> going with ShEx would present a much clearer stance on this issue, which is very attractive to me
19:06:02 <kcoyle> Arnaud: can we cover abstract syntax without Arthur?
19:09:10 <Labra> q+
19:09:17 <kcoyle> ericP: offering an abstract syntax from shex
19:09:32 <Arnaud> ack Labra
19:10:28 <kcoyle> Labra: also volunteered work on translation from shex to shacl will require abstract syntax and he volunteers to work on this
19:10:50 <kcoyle> ericP: our tests already map to abs.syn
19:11:33 <kcoyle> Arnaud: encourages eric and jose to take this on, since arthur has a lot on his plate
19:12:28 <kcoyle> ... we'llw ait for first draft from eric and jose
19:13:19 <kcoyle> ericP: hopes to get a few minutes of arthur's time at the beginning
19:13:55 <Arnaud> https://www.w3.org/2014/data-shapes/track/issues/open
19:14:19 <kcoyle> ISSUE: 108
19:14:20 <trackbot> Created ISSUE-116 - 108.  Please complete additional details at <http://www.w3.org/2014/data-shapes/track/issues/116/edit>.
19:14:28 <kcoyle> oops
19:14:33 <Arnaud> topic: ISSUE-108
19:14:33 <trackbot> issue-108 -- Should operations be specified? -- open
19:14:33 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/108
19:15:36 <kcoyle> hknublau: can be dropped, if we decide what to do with value function
19:15:46 <kcoyle> pfps: they were supposed to be optional
19:16:24 <kcoyle> ... something needs to say what kicks off validation (interface)
19:16:56 <kcoyle> ... spec could say: validation happens when you are given two graphs; everything else is optional; just one required interface
19:17:36 <kcoyle> hknublau: looking at 10.3; clarifying role of filterShape. onlyvalidated if matches filter shape
19:17:44 <pfps> I am against having aspects of the spec only show up in java code
19:17:52 <kcoyle> operation would be a formal answer to those questions
19:17:59 <pfps> q+
19:18:04 <Arnaud> ack pfps
19:18:44 <kcoyle> pfps: proposes: get rid of section 10; say "the interface is the graph interface' and make sure that rest of spec nails down what happens when you kick off validation
19:18:54 <kcoyle> ... given a shapes graph and a data graph
19:19:28 <Dimitris> what about instance validation?
19:19:29 <kcoyle> hknublau: ok to close
19:19:54 <Dimitris> I am also fine to close it as suggested
19:20:03 <pfps> PROPOSAL: The one specified way to invoke SHACL validation is an interface that takes a data graph and a shapes graph.
19:20:19 <kcoyle> +1
19:20:32 <Dimitris> +1
19:20:37 <pfps> +1
19:20:41 <Dimitris> q+
19:20:48 <hknublau> +1
19:20:53 <Arnaud> ack Dimitris
19:21:04 <ericP> q+
19:21:27 <ericP> q-
19:21:36 <kcoyle> (I didn't get that - Dimitris pls scribe your statement)
19:22:14 <kcoyle> pfps: you can be conformant if the only interface is "give me two graphs"
19:22:46 <Dimitris> asked if validating an instance against a shape is supported by the porposal
19:22:48 <kcoyle> Arnaud: You can always do more; this is the minimum
19:22:51 <ericP> q+ to ask if the manifest format makes a tester compliant
19:22:59 <Arnaud> ack ericP
19:22:59 <Zakim> ericP, you wanted to ask if the manifest format makes a tester compliant
19:23:47 <kcoyle> ericP: manifest has a schema doc and a data doc, a schema node and a focus node... implies an API that takes four arguments...
19:24:00 <kcoyle> ... manifest is a control structure
19:24:46 <kcoyle> pfps: extra arguments are how you add control to shapes graph. testing environ is to set up shape and data graphs
19:25:17 <kcoyle> ... or have control to start validation in a different place
19:25:31 <kcoyle> ... just want something written so that we can define conformant
19:26:29 <kcoyle> ericP: in sparql working group never specified how most queries are executed; assumed people would do the right thing
19:26:34 <kcoyle> pfps: that's a pain point
19:28:46 <kcoyle> pfps: maybe there should be another interface that has an implicit data graph
19:28:52 <ericP> +0
19:29:07 <kcoyle> ericP: not sure this is the best way, but a stake in the ground
19:29:52 <Arnaud> RESOLVED: Close ISSUE-108, the one specified way to invoke SHACL validation is an interface that takes a data graph and a shapes graph.
19:30:11 <Dimitris> issue 80 should be easy
19:30:35 <kcoyle> topic: ISSUE-80
19:30:35 <trackbot> issue-80 -- Constraint to limit IRIs against scheme/namespace, possibly with dereferencing -- open
19:30:35 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/80
19:31:12 <pfps> ok by me
19:31:33 <Dimitris> ok by me too (Excluding the dereferencing)
19:31:54 <kcoyle> pfps: doesn't like "valueScheme" because of "scheme"
19:32:11 <kcoyle> ericP: this is stemming in shex
19:33:10 <kcoyle> "valueStem" is consistent with SHACL
19:33:45 <kcoyle> hknublau: isn't this already done with regex? diff here is checking to see if resource exists
19:34:20 <kcoyle> ericP: semantics can't be matched to long list of 'or's
19:34:38 <kcoyle> ... each stem is disunct -- specialization of regex
19:34:40 <pfps> this appears to be a conjunction of IRI & pattern
19:34:46 <kcoyle> q+
19:35:05 <Arnaud> ack kcoyle
19:36:13 <kcoyle> kcoyle: two things - pattern matching and external resolution
19:37:15 <kcoyle> ericP: many ways folks want to deal with value sets, from enumeration to provenance to dereference and diff kinds of dereference
19:37:32 <kcoyle> ... e.g. is subclass of X
19:38:44 <kcoyle> ... problem is that it's time dependent
19:38:56 <kcoyle> Arnaud: this adds something we haven't had before now
19:39:04 <kcoyle> ericP: not a version one feature
19:40:12 <kcoyle> Arnaud: does sh:Pattern address this?
19:40:32 <kcoyle> ... having stem is syntactic sugar
19:43:18 <ericP> kcoyle: thinking about how [bark bark] you can tests to see [bark bark] that you have a DOI
19:44:27 <Arnaud> PROPOSED: Close ISSUE-80, accepting the proposed addition of sh:valueScheme renamed as sh:valueStem, and leaving resource resolution/fetching to a future version of SHACL
19:45:29 <ericP> +1
19:45:50 <Dimitris> +1
19:45:56 <pfps> +0.5
19:47:22 <kcoyle> hknublau: what are we gaining here? this saves one character?
19:49:11 <kcoyle> ericP: user-friendliness. works when you have a value list
19:50:54 <kcoyle> ericP: stems different from uri's.
19:51:08 <ericP> [ a sh:PropertyConstraint ; sh:values ( [ a sh:Stem ; sh:stem foaf: ] [ a sh:Stem ; sh:stem dc:cre ] ) ]
19:52:10 <kcoyle> hknublau: that's an or? need to make this clear; maybe not enough info to close this issue?
19:52:57 <kcoyle> ericP: allowed values are a sequence of terms (?), so effectively an or
19:53:51 <kcoyle> Arnaud: eric, put proposal in an email so we have a clear description
19:54:51 <kcoyle> ericP: discuss resolving resources
19:57:08 <kcoyle> karen will talk to holger about using named graphs to resolve this
19:58:22 <kcoyle> closing the call
19:58:26 <hknublau> Next meeting hopefully in Nuuk time zone.
19:58:33 <kcoyle> next call January 7
19:59:33 <Arnaud> trackbot, end meeting
19:59:33 <trackbot> Zakim, list attendees
19:59:33 <Zakim> As of this point the attendees have been hknublau, Arnaud, Dimitris, aryman, simonstey, ericP, iovka, labra, pfps, kcoyle
19:59:39 <Dimitris> Dimitris has left #shapes
19:59:41 <trackbot> RRSAgent, please draft minutes
19:59:41 <RRSAgent> I have made the request to generate http://www.w3.org/2015/12/17-shapes-minutes.html trackbot
19:59:42 <trackbot> RRSAgent, bye
19:59:42 <RRSAgent> I see no action items