IRC log of shapes on 2015-05-20

Timestamps are in UTC.

12:57:53 [RRSAgent]: RRSAgent has joined #shapes
12:57:53 [RRSAgent]: logging to http://www.w3.org/2015/05/20-shapes-irc
12:57:55 [trackbot]: RRSAgent, make logs rdf-data-shapes
12:57:57 [trackbot]: Zakim, this will be SHAPES
12:57:57 [Zakim]: I do not see a conference matching that name scheduled within the next hour, trackbot
12:57:58 [trackbot]: Meeting: RDF Data Shapes Working Group Teleconference
12:57:58 [trackbot]: Date: 20 May 2015
12:58:27 [Arnaud]: the webex access code has changed, make sure you reload the wiki page
12:59:23 [Arnaud]: ccess code is: 642 797 732
13:00:04 [ericP]: ericP has changed the topic to: RDF Data Shapes WG: https://www.w3.org/2014/data-shapes/ - New webex code: 642 797 732 Next agenda: https://www.w3.org/2014/data-shapes/wiki/F2F3#Agenda Use WebEx for audio connection - see F2F page for details
13:00:46 [Dimitris]: Dimitris has joined #shapes
13:02:15 [aryman]: aryman has joined #shapes
13:05:07 [hsolbrig]: hsolbrig has joined #shapes
13:06:08 [pfps]: pfps has joined #shapes
13:06:13 [pfps]: Hi.
13:12:12 [Dimitris]: scribenick: dimitris
13:12:38 [Dimitris]: arnaud: what would it take for you to live with the other proposals?
13:13:30 [Dimitris]: ... identify gaps
13:13:31 [Labra]: Labra has joined #shapes
13:13:47 [Dimitris]: ... start with the presenters and go from there
13:14:29 [ericP]: definition for recursion, graph coverage and closed shapes, oneOf, multi-occurance, negation
13:14:30 [Dimitris]: ericp: if we abandon our semantics we have no guarantee
13:15:16 [Dimitris]: ... it's tempting to write these out of shacl
13:15:32 [Dimitris]: and find a subset of shex that matches the semantics
13:16:52 [Dimitris]: ... the sparql version increased in complexity
13:18:01 [hknublau]: +q
13:18:47 [Dimitris]: pfps: having named things and reference other things does not mean we allow recursion
13:19:26 [hsolbrig]: +q
13:19:39 [Dimitris]: ericp: from the user perspective people will do recursion so is this a compile time syntax error?
13:20:42 [Dimitris]: pfps: there are certain recursion patterns shex does not allow
13:21:30 [aryman]: q+
13:21:34 [Labra]: q+
13:21:56 [Arnaud]: ack hknublau
13:22:57 [Dimitris]: hknublau: if we intersect a core and each goes his own way we won't be succesful
13:23:24 [Dimitris]: ... we should come up with a definition that satisfies requirements
13:24:37 [pfps]: I agree with Holger, most of Eric's list is quite simple in a SPARQL-based solution.
13:24:39 [Dimitris]: arnaud: I agree with holger
13:25:02 [hsolbrig]: q-
13:25:26 [Arnaud]: ack aryman
13:26:33 [Dimitris]: aryman: seeing Peter's proposal the grammar does permit recursion but that's not the full definition of a language
13:28:01 [Dimitris]: pfps: (giving a more formal definition)
13:29:07 [Dimitris]: aryman: I agree with Holger, we need to address all problems
13:29:07 [Arnaud]: ack Labra
13:29:10 [pfps]: The grammar of the language is the grammar of the language. Context-free grammars are often used as over-generalizations of the grammar of a language, and have implementation advantages.
13:30:19 [Labra]: http://www.slideshare.net/jelabra/linked-dataquality-2014
13:30:23 [Dimitris]: labra: it is quite normal & natural to have cycles like in RDF e.g. foaf:knows
13:30:26 [Labra]: slide 6
13:31:10 [Dimitris]: in this slide recursion is needed
13:31:44 [pfps]: But having loops in the data is not by itself an argument for recursion.
13:32:39 [Dimitris]: arnaud: we will see about recusrion later, Holger what would it take for you to live with Eric's or Peter's proposal?
13:33:02 [Dimitris]: hknublau: it's easier with Peter's proposal
13:33:16 [hsolbrig]: q+
13:33:44 [pfps]: The difference between my proposal and Holger's are lessening, and not ones of kind.
13:34:19 [Dimitris]: ... PEter's proposal is not as complete as mine but by merging we can make it. With ShEx it's quite different because SPARQL is a second-class citizen in the language.
13:34:31 [Dimitris]: s/PEter/peter/
13:35:35 [Dimitris]: ... we complicate shacl too much
13:36:22 [kcoyle]: q+
13:36:38 [Arnaud]: ack hsolbrig
13:36:43 [Dimitris]: ... we can have a separate semantics document, compact syntax along with the main proposal
13:37:37 [Dimitris]: hsolbrig: referring to Jose's slide 6, is this the recursion we are referring to?
13:37:50 [Dimitris]: pfps: this is loops in the data model
13:38:10 [Labra]: +q
13:38:36 [Dimitris]: hsolbrig: all we need is to model with shapes the uml diagram
13:38:46 [Dimitris]: pfps: it can be done without recursion
13:39:26 [Dimitris]: ... we have two sides a constraints side and a recognition side
13:43:24 [Dimitris]: hsolbrig: eric is there something more that we need to do beyond the slide 6?
13:44:08 [kcoyle]: q-
13:44:46 [Dimitris]: pfps: in the constraint side you don;t have to use recursion because you don't need it
13:45:02 [Dimitris]: .. and the data loops tie everything together
13:45:53 [Dimitris]: ericp : because we have a type arc?
13:46:10 [Dimitris]: pfps: usually we have a type arc but it is not necessary
13:46:27 [aryman]: q+
13:46:47 [Labra]: q+
13:47:16 [Labra]: another example: http://www.slideshare.net/jelabra/towards-an-rdf-validation-language-based-on-regular-expression-derivatives
13:47:19 [Labra]: slide 4 there
13:48:06 [Dimitris]: ... even if you took owl recognition in a CWA owl is more powerful than ShEx
13:49:21 [Dimitris]: pfps: it wouldn't work in e.g. ir ex:reportedBy was the only way to identify the issue
13:50:21 [pfps]: I don't think that constraints can do something like saying that issues are those things whose related things are issues.
13:50:47 [kcoyle]: q+
13:52:02 [Dimitris]: hsolbrig: I didn't see Peter's proposal but I 'd excited to merge Eric's and Holger's
13:52:57 [Dimitris]: ... what Holger states as templates fits very well to Eric's semantic actions
13:54:27 [Arnaud]: ack Labra
13:54:46 [Labra]: another example: http://www.slideshare.net/jelabra/towards-an-rdf-validation-language-based-on-regular-expression-derivatives
13:56:07 [Dimitris]: labra: I put another sample in slide 4 but you don't have a type arc. We need shacl to identify this data models
13:56:41 [Dimitris]: ... we should try to identify an expressive enough core language like choices, conjuction
13:56:53 [Arnaud]: ack aryman
13:57:04 [Dimitris]: ... if have these constructs I don't mind having other extension mechanisms
13:57:15 [pfps]: I dispute the Person example. The RDF data does not match the E-R diagram.
13:58:24 [Labra]: q+
13:58:42 [Arnaud]: ack Labra
13:58:46 [Dimitris]: pfps: (about slide 6) since we have rdf:type in the ER we can do everything
13:59:16 [Dimitris]: labra: the rdf:type could be missing
14:00:26 [Dimitris]: pfps: in ER every entity belongs to a class, even for the person example there has to be an indication that it is a person
14:00:29 [ericP]: q?
14:01:17 [Dimitris]: labra: we are not modelling ER we are modelling data
14:01:41 [hsolbrig]: q+
14:02:23 [ericP]: so does every node except the top in pfps's proposal need a descriminator?
14:03:27 [Dimitris]: aryman: I agree with peter about ER but in practice let's assume we don't have type triples
14:03:53 [pfps]: The diagram says "E-R Diagram" ! So it *is* an E-R diagram!
14:04:16 [Arnaud]: :)
14:04:23 [Labra]: I called the diagram E-R because it is familiar to people
14:04:29 [Labra]: but it is a RDF data model
14:04:40 [Labra]: we are not modelling an RDF database
14:05:26 [Dimitris]: ... in this case there cycles
14:05:31 [hsolbrig]: q-
14:05:36 [Labra]: I mean, it is not a E-R diagram in the classic term of relational databases
14:05:42 [Arnaud]: ack kcoyle
14:06:29 [pfps]: E-R diagrams aren't relational databases, so I'm not sure why the need to distinguish them
14:07:07 [Dimitris]: kcoyle: I like meting the ShEx syntax with a backend like Holger's or Peter's proposal but if we need SPARQL 50% we don;t do a good job
14:07:20 [pfps]: If the SHACL proposals look too programmy, then what would make them less programmy?
14:07:20 [Dimitris]: ... the core should protect people from SPARQL
14:07:39 [pfps]: Perhaps you are agling for something like OWL contraints, as in Stardog ICV.
14:07:55 [Dimitris]: arnaud: What would it take for you to live with the other proposals?
14:08:38 [Dimitris]: pfps: Mine and Holger's proposal are getting closer so it wouldn't be too much, the only issue would be shapes are classes
14:09:30 [Dimitris]: ... for the ShEx proposal, to have something so different in a W3C standard would quite hard for me
14:10:10 [Dimitris]: ... only if we had the ShEx semantics but why go with something that is new, untried when there is a good alternative
14:10:46 [Dimitris]: ... it has to be cleaner than Caesar's wife
14:11:40 [Dimitris]: ... shex has problems to translate into SPARQL and the other is global coverage, although coverage looks it dropped from the proposal
14:12:37 [Dimitris]: ... adding recursion or coverage could cause everything to break
14:13:15 [Dimitris]: arnaud: we can accept features on not when time comes
14:14:12 [hknublau]: +q
14:14:33 [Dimitris]: ... Karen as a normal user is not font of using SPARQL
14:14:40 [hknublau]: -q
14:15:03 [hknublau]: Yes, Karen’s concers can be addressed by tools providing a high-level front end.
14:15:07 [Dimitris]: pfps: Karen is wrong and even with ShEx we would have to resort to another language anyway
14:15:19 [hknublau]: Our examples were cryptic because they were in RDF.
14:16:41 [Dimitris]: arnaud: we can decide where we draw the line between core and extensions
14:17:47 [Dimitris]: ... Holger proposed to start with a minimal set and extend with user need which is a conservative approach
14:17:59 [pfps]: +1 to holger - the SPARQL-based syntaxes are RDF-encodings, which are ugly at best
14:18:48 [Dimitris]: ... css was created from the ground up in W3C
14:18:50 [Labra]: q+
14:18:57 [Arnaud]: ack Labra
14:19:59 [Dimitris]: labra: we need to agree on constructs, Holger wanted a minimal core we want something more
14:20:46 [pfps]: I'm not sure why having something not be in the core would prevent it from being interoperable.
14:20:57 [ericP]: q+ to say that i started out only caring about the surface syntax, but then had to meet more use cases. Won't we face the same problem here?
14:21:13 [hsolbrig]: q+
14:21:18 [Arnaud]: ack ericP
14:21:18 [Zakim]: ericP, you wanted to say that i started out only caring about the surface syntax, but then had to meet more use cases. Won't we face the same problem here?
14:22:02 [Dimitris]: ericp: the syntax grew based on user demans
14:22:20 [hsolbrig]: s/demans/demons/
14:22:45 [pfps]: I think that Jose was arguing for only standardizing the core. I am against that.
14:23:00 [Dimitris]: ... and that is how complexity grew as well
14:23:45 [Arnaud]: ack hsolbrig
14:23:55 [Dimitris]: arnaud: we need to make sure the different documents be in sync
14:25:19 [Dimitris]: hsolbrig: I am ok to add syntactic sugar on top of SPARQL but not on rejecting constructs because they cannot be translated to SPARQL
14:26:37 [Labra]: q+
14:26:39 [hknublau]: +q
14:26:48 [Arnaud]: ack Labra
14:27:51 [Dimitris]: labra: the usual cases should not need SPARQL
14:27:54 [Arnaud]: ack hknublau
14:28:10 [pfps]: As soon as you have inter-property relationships you have to drop into SPARQL in any of the proposals.
14:29:17 [Dimitris]: hknublau: SPARQL is complex but is also powerful, if you want something wil a lot expressivity will turn out to something like SPARQL in the end and a new language for users to learn
14:29:35 [pfps]: Of course, you could always add new constructs to cover these situatons. In the SPARQL-based proposals this amounts to writing the translation into SPARQL.
14:29:36 [Dimitris]: ... any other alternative will become just as complex
14:33:31 [Arnaud]: http://doodle.com/qhpf64i2rn6283c9#table
14:34:05 [Arnaud]: break for 15mn
14:51:14 [ericP]: scribenick: ericP
14:53:21 [hknublau]: +q
14:53:35 [Arnaud]: ack hknublau
14:54:46 [aryman]: can we at least do a straw poll to gauge the wg's mood?
14:57:04 [kcoyle]: I don't think this solves my issues, and I'd need more info (eg test examples)
14:57:05 [aryman]: q+
14:57:12 [Arnaud]: ack aryman
14:58:45 [Arnaud]: PROPOSED: Merge Peter and Holger's proposals
14:58:53 [aryman]: +1
14:58:59 [hknublau]: +1
14:59:20 [kcoyle]: kcoyle +1 (although I don't really know what that means)
14:59:35 [pfps]: We don't have a direction for the merge yet, but I'm not against this in principle.
14:59:41 [pfps]: 0
14:59:58 [Dimitris]: +1
15:00:16 [hsolbrig]: q?
15:00:31 [pfps]: I don't think that there would be much, if any, reduction in the total cognitive load.
15:00:53 [pfps]: The biggest difference is between the SHACL-based solutions and the ShEx-like solution.
15:01:25 [hsolbrig]: I'm not sure I understand Peter's proposal so I can't vote
15:01:49 [ericP]: pfps: why bother?
15:02:07 [hsolbrig]: My understanding it that it says "We don't need SHACL, just Sparql.." Is this not the case?
15:02:19 [ericP]: Arnaud: i have the feeling that there is an aspect to your proposal that is not in Holger's which his draft would benefit from
15:02:39 [ericP]: ... we talked yesterday about how what you call a constraint is different than Holger's
15:03:09 [ericP]: ... so if your terminology is better, would it be better in Holger's doc?
15:03:40 [ericP]: pfps: why weaken our proposals?
15:03:47 [ericP]: ... we're stuck on this divide
15:04:00 [ericP]: ... between the SPARQL-based and the non-SPARQL-based solutions
15:04:36 [ericP]: ... the ShEx solution is not SPARQL-based. it has SPARQL as an add-on but it has a different semantic base.
15:05:28 [ericP]: ... at some point we need to tie up one or both approaches
15:06:13 [ericP]: ... it's hard for me to imagine what shex folks could do that would make me accept it
15:06:36 [ericP]: Arnaud: i'm talking about implementing ShEx in SHACL
15:07:02 [ericP]: pfps: that that means the ShEx folks have to give up on some stuff that they deem important
15:07:36 [ericP]: Arnaud: can we evaluate what can be done in SPARQL?
15:08:04 [ericP]: pfps: let's first ask what will be the semantic underpinnings
15:09:07 [Arnaud]: PROPOSED: Define a compact syntax for SHACL, along the lines of ShEx
15:09:26 [ericP]: pfps: i'm all for a nice syntax for SHACL
15:09:51 [ericP]: aryman: then we can isolate the differences to a few features
15:10:41 [ericP]: Arnaud: do you want to say "ShEx people, go away; you want stuff that can't be implemented in SPARQL"
15:10:53 [ericP]: pfps: for me, "yes"
15:11:19 [ericP]: ... but we're asking the ShEx folks to give up on their semantics, coverage, recursion, etc...
15:11:50 [ericP]: aryman: ericP did say that compact syntax was the original motivation for ShEx
15:12:22 [ericP]: pfps: so this means that the only thing that remains is the syntax
15:13:16 [ericP]: Arnaud: iovka's not here, but she did say "are you going to reinvent this all?"
15:13:39 [ericP]: pfps: why should the SPARQL side be against this approach?
15:14:07 [ericP]: Arnaud: the caveat is that you have to have an open mind and extend SPARQL when necessary
15:15:01 [ericP]: ... iovka et al may continue to work on this elsewhere
15:15:26 [ericP]: pfps: it's always going to be the case that we have to ask will each feature be worth the pain?
15:16:13 [ericP]: hsolbrig: there's going to be an outer control logic which we can augment
15:16:42 [hknublau]: (Not hsolbrig, hknublau)
15:17:12 [ericP]: aryman: there's a big intersection; we should look at the remaining features and evaluate their use and cost
15:17:21 [Arnaud]: s/hsolbrig/hknublau/
15:19:48 [pfps]: Eric is proposing something very different from what I thought was the way forward.
15:20:01 [pfps]: And it's not the same at all as "meeting the use cases".
15:21:30 [pfps]: Multiple pieces of a shape that are about the same property were problematic in ShEx, but they cause no problems in the SPARQL-based solutions.
15:21:44 [pfps]: q+
15:22:08 [Arnaud]: ack pfps
15:22:36 [ericP]: pfps: ericP appears to be arguing for a particular way of solving the use cases, not solving them.
15:23:20 [ericP]: q+
15:24:56 [Arnaud]: ack ericP
15:25:13 [ericP]: <S> { :performer { :role :surgeon } , :performer { :role :anesthtisiologist } }
15:25:13 [Arnaud]: you're fading again
15:25:24 [Arnaud]: can barely hear you
15:25:31 [aryman]: hard to hear eric
15:25:39 [pfps]: Again, Karen's desire to not drop into SPARQL does not distinguish between *any* of the proposals.
15:26:07 [ericP]: ericP: i didn't intend to say that i need to want a particular methodology; just that my guess is that iovka's semanttics will be useful in defining the control structure semantics
15:27:00 [ericP]: pfps: how does distinguish between the different possiblities?
15:27:35 [ericP]: Arnaud: i think it depends on the different features
15:28:11 [kcoyle]: can't we resolve this with test cases? this is speculation
15:28:51 [ericP]: pfps: ShEx has featues that aren't in the RDF encoding of holger's proposal
15:29:13 [hsolbrig]: I'll do it
15:29:40 [Arnaud]: thanks
15:29:47 [hsolbrig]: pfps: There are a couple of things in ShEx that don't fit into Sparql as well as other things in the past
15:30:25 [hsolbrig]: pfps: The SPIN "family" SPIN, RDF Constraints, Stardog doesn't see much of a need for that
15:31:11 [hsolbrig]: hknublau: Eric's exmple could be expressed in pure SPARQL or just another template.
15:31:51 [hsolbrig]: pfps: Anything that you can fit into a closed world OWL axiom, if will fit within the "most stark SPARQL setup"
15:32:01 [hsolbrig]: s/if/it/
15:33:00 [hsolbrig]: Arnaud: Propose we take Peter's draft and agree to merge and define compact syntax along the lines of ShEx. If things don't fit, we will have to decide which way we go.
15:33:44 [hsolbrig]: Arnaud: In the end, if compact is not rich enough for ShEx, they can go on. Rest of group will not agree to base the whole standard on ShEx.
15:34:17 [hsolbrig]: pfps: If that is the premise, the work that Holger and I would do would likely have impact. I'm all for it.
15:35:42 [Arnaud]: PROPOSED: Adopt Holger's draft as SHACL, leveraging Peter's proposal to improve it, and define a compact syntax for it along the lines of ShEX
15:35:56 [hknublau]: +1
15:35:58 [pfps]: +1
15:35:59 [kcoyle]: +1
15:36:00 [aryman]: +1
15:36:19 [hsolbrig]: +0
15:36:25 [ericP]: +0 # i'm not sure if this rules out ShEx use cases
15:36:43 [Labra]: Labra has joined #shapes
15:36:51 [Dimitris]: +1
15:37:04 [pfps]: This is a fundamental vote, so I expect it will need to be confirmed by the WG as a whole.
15:40:17 [Labra]: Labra has joined #shapes
15:40:24 [Labra]: I have just connected
15:40:28 [pfps]: I thought that, in general, substantive votes should be announced in advance, so that WG members who care can do their homework.
15:40:41 [Arnaud]: PROPOSED: Adopt Holger's draft as SHACL, leveraging Peter's proposal to improve it, and define a compact syntax for it along the lines of ShEX
15:40:53 [Labra]: -1
15:42:18 [hsolbrig]: labra: When I wanted to add a language construct in the past, Holger answered that template mechanism covered it and I wanted things to be well defined and identified.
15:43:04 [hsolbrig]: arnaud: I would expect those issues to be addressed in the proposal I made, and if the group agrees that they should be added, they would be added.
15:43:59 [aryman]: q+
15:44:01 [hsolbrig]: labra: I think we need a more useful, expressive core language. Disjunctions are left, ... doesn't say whether they are adopted or not. Any time we want to add a feature, we have to create another issue..
15:46:19 [hsolbrig]: labra: I could add an issue for features in the abstract syntax, but that isn't a way forward. User can add his own features isn't the answer...
15:46:43 [Arnaud]: ack aryman
15:47:36 [hsolbrig]: aryman: I think the group agrees that we have to proceed from use cases, not just features. If the use case is a general useful constraint, we need to represent it in the language. Define as template and then promote as part of core langauge.
15:48:14 [Arnaud]: PROPOSED: adopt ShEx's abstract syntax as the starting point and align everything else (i.e., RDF vocab and Compact Syntax) to it
15:48:24 [hsolbrig]: aryman: If you agree that we proceed based on use cases, then there is pretty much concensus that that is what goes into the core.
15:48:26 [pfps]: It can also be the case that the features needed to cover a desirable set of use cases do not result in an implementable system.
15:48:27 [Labra]: +1
15:48:27 [pfps]: -1
15:48:28 [aryman]: -1
15:48:29 [hknublau]: -1
15:48:41 [kcoyle]: +0
15:48:42 [ericP]: +1 # of course
15:48:43 [hsolbrig]: +1
15:48:47 [Dimitris]: -1
15:49:20 [hsolbrig]: Arnaud: This is a clear non-starter
15:49:21 [kcoyle]: Jose: you need to mute
15:49:42 [pfps]: eric - why of course? this indicates that you are aligned to a particular solution
15:50:03 [ericP]: because it meets the use cases we've seen
15:50:26 [hsolbrig]: arnaud: More pragmatic to start with something minimal and then extend.
15:50:47 [ericP]: now we run the obvious risk that any feature that's inconvenient will be struck from the language
15:50:59 [pfps]: eric - so what? why not permit different solutions to the problems you have seen?
15:52:03 [ericP]: pfps, i think my last line answers that. do you disagree? (i'm not prescribing solutions, just language featuers)
15:52:58 [pfps]: q+
15:52:58 [hsolbrig]: Arnaud: This is as far as we can take this today. We should focus on trying to solve some of the issues we have.
15:53:11 [Arnaud]: ack pfps
15:53:32 [hsolbrig]: pfps: Why not just vote to disband the working group?
15:54:27 [hsolbrig]: Arnaud: not the group's decision. As chair I have the right to override one negative and it can be appealed if voter wishes.
15:55:02 [Labra]: q+
15:55:24 [aryman]: q+
15:56:05 [Arnaud]: ack Labra
15:57:29 [hsolbrig]: Labra: This vote is quite important. We could have an offline vote...
15:57:36 [Arnaud]: ack aryman
15:58:24 [hsolbrig]: Arthur: I think ShEx folks are concerned that their use cases may not be represented in the solution... lets focus on use cases.
15:59:15 [hsolbrig]: Arthur: I think we should spend a lot more effort on the test suite and give others an opportunity to solve them. Lets not talk in generalities, focus on the specific and concrete.
15:59:30 [ericP]: q+ to ask if we can write ShExC tests
16:00:53 [hsolbrig]: Arnaud: I agree. Even if you accept the general approach, doesn't mean that you can't object to the particular solution and say I'm not happy because it is missing something I need.
16:00:59 [pfps]: eric - but language features are in essence solutions
16:01:32 [Labra]: q+
16:01:38 [Arnaud]: ack ericP
16:01:38 [Zakim]: ericP, you wanted to ask if we can write ShExC tests
16:02:14 [aryman]: q+
16:03:05 [Arnaud]: ack Labra
16:03:12 [hsolbrig]: Arnaud: This is the kind of question we can address tomorrow. We may want two different test sets -- compact syntax and another to be certain of coverage
16:05:11 [hsolbrig]: Arnaud: vote is not resolved. Considering putting it offline but worried about votes without context and ...
16:07:21 [aryman]: used to be that if you missed two meetings in a row then you could not vote
16:07:52 [aryman]: also, only one vote per org
16:08:32 [Arnaud]: ack aryman
16:08:39 [aryman]: re test cases, they should contain data
16:09:44 [hsolbrig]: aryman: The test cases should be described with data -- example that validates, example that violates. Syntax should be documentation, but not definition.
16:10:22 [hsolbrig]: Lunch break. After lunch discussion of issues
16:17:11 [michel]: michel has joined #shapes
17:04:55 [Labra]: hi
17:07:18 [hsolbrig]: scribenick: hsolbrig
17:08:00 [hsolbrig]: Arnaud: Look at issues list. Should wait for pfps for inferencing.
17:08:09 [pfps]: I'm back, more or less.
17:08:35 [Arnaud]: back enough to talk about inferencing?
17:08:52 [pfps]: not for a bit - I have to do a bit more cleanup
17:09:31 [hsolbrig]: Arnaud: Issue 37
17:09:48 [iovka]: iovka has joined #shapes
17:10:10 [hsolbrig]: Issue 37 requires Ted...
17:10:20 [hsolbrig]: Arnaud: Lets look at the list in general
17:11:02 [hsolbrig]: Arnaud: Issue 25 -- what's in core?
17:11:51 [hsolbrig]: Arnaud: No simple answer. I don't think we can draft a resolution, the answer will evolve over time.
17:12:05 [hsolbrig]: Holger: I think it should be split into sub issues
17:12:40 [hsolbrig]: Arnaud: I think we can close 25.
17:12:51 [Arnaud]: PROPOSED: Close ISSUE-25, as is - this will be defined over time on a case by case basis
17:12:54 [hknublau]: +1
17:12:56 [hsolbrig]: +1
17:13:00 [kcoyle]: +1
17:13:06 [Labra]: +1
17:13:09 [michel]: +1
17:13:29 [Dimitris]: +1
17:13:34 [aryman]: aryman has joined #shapes
17:13:37 [aryman]: +1
17:13:47 [Arnaud]: RESOLVED: Close ISSUE-25, as is - this will be defined over time on a case by case basis
17:15:29 [hsolbrig]: Holger: Issue 24 -- haven't seen it in other proposals. Can we just say that inheritence resolves it via rdfs mechanisms?
17:15:30 [Arnaud]: Issue-24
17:15:30 [trackbot]: Issue-24 -- Can shapes specialise other shapes? -- open
17:15:30 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/24
17:15:57 [Dimitris]: I would be fine with Holger's approach
17:16:05 [aryman]: q+
17:16:38 [hknublau]: +q
17:17:16 [Dimitris]: ericp. property paths can be used for closure
17:17:41 [Arnaud]: ack aryman
17:18:13 [hsolbrig]: aryman: I don't think this has anything to do with classes and inferencing. we've already agreed that they are different things.
17:18:59 [hsolbrig]: aryman: specializing shapes is totally orthogonal to classes, meaning, "When you evaulate this shape, first evaluate that". A specialized constraint should match less...
17:19:20 [hsolbrig]: arnaud: Holger is saying that shape is a class...
17:19:35 [Arnaud]: ack hknublau
17:19:41 [hsolbrig]: aryman: Not in Peter's proposal. There is a class of all shapes, but a shape isn't a class.
17:20:02 [aryman]: q+
17:20:20 [ericP]: does that only apply if classShape is used?
17:20:26 [hsolbrig]: holger: it doesn't depend on the shape/class link. There is scopeClass and inheritence in RDFS gives us what we want.
17:20:32 [Arnaud]: ack aryman
17:21:09 [hsolbrig]: aryman: scopeClass, at least in Peter's proposal is something different. It says, "only apply this shape if this scope shape is true". It doesn't say this shape extends another shape..
17:21:47 [hsolbrig]: aryman: Not the same as class inheritence in RDF
17:22:40 [ericP]: here's what inclusion looks like in ShExC: http://w3.org/brief/NDUx
17:22:44 [hsolbrig]: aryman: completely othogonal to rdfs inheritence. Like an inclusion macro -- can add or strengthen. 0..* can be constrained to 0..1
17:23:41 [hsolbrig]: aryman: based on constraints being open. Could only strengthen if closed
17:23:44 [ericP]: q+ to say what this looks like in ShExC
17:23:55 [Arnaud]: ack ericP
17:23:55 [Zakim]: ericP, you wanted to say what this looks like in ShExC
17:25:49 [pfps]: posting the syntax on IRC would be more helpful, I think
17:25:59 [hsolbrig]: ericp: &<personshape> states "inheritence"
17:26:41 [pfps]: how is that different from just conjoining the shape in?
17:26:55 [hsolbrig]: holger: we have two mechanisms, what are the consequences?
17:26:57 [ericP]: here's another view of it: http://piratepad.net/shacl
17:27:28 [hsolbrig]: aryman: if you scope the shape by a type and do proper inferencing you achieve the desired effect. We aren't requiring a shape to be linked to a class.
17:28:00 [pfps]: q+
17:28:05 [hsolbrig]: aryman: in some graphs you can have nodes that have the same type but you want to enforce different shapes.
17:28:21 [hsolbrig]: holger: This is whe we've introduced the pre-condition scopes.
17:28:34 [hsolbrig]: s/whe/why/
17:28:55 [Arnaud]: ack pfps
17:28:58 [simonstey]: simonstey has joined #shapes
17:29:21 [hsolbrig]: pfps: & means textual inclusion -- place them together?
17:29:36 [iovka]: +q
17:29:47 [hsolbrig]: ericp: Yes - its a group, not conjunction.
17:29:53 [Arnaud]: ack iovka
17:30:21 [hsolbrig]: iovka: ??? (audio garbled)
17:31:11 [hsolbrig]: pfps: It is a question on what the syntax means. You said you could do conjunction by two separate shapes...
17:32:17 [hsolbrig]: iovka: You don't need to model it with grouping. This is kind of equivalent to conjunction because both shapes are satisfied.
17:33:03 [hsolbrig]: +q
17:33:10 [pfps]: It's not even that I thought that it was logical conjunction. I was just asking what the combination construct was here.
17:33:48 [hsolbrig]: aryman: it is very ackward to have to construct shapes by copying, pointer needed.
17:33:52 [Arnaud]: ack hsolbrig
17:34:53 [hsolbrig]: hsolbrig: Can we all agree that shape specialization is needed?
17:35:32 [hsolbrig]: arnaud: Yes - how is more complicated, but can we clarify we agree?
17:36:09 [pfps]: pfps has joined #shapes
17:36:12 [pfps]: q+
17:36:24 [Arnaud]: ack pfps
17:36:26 [hsolbrig]: arnaud: two possible ways, leverage rdfs inheritence. Other way is we develop our own mechanism
17:36:52 [hsolbrig]: pfps: All of the proposals include some kind of conjunction? If so, we've already done it...
17:37:09 [iovka]: +q
17:37:17 [Arnaud]: ack iovka
17:38:43 [hsolbrig]: holger: We can add a 3 line template that would handle conjunction...
17:39:27 [hsolbrig]: aryman: closed shape, doesn't make sense to add additional properties. Once you've closed it, nothing below it can add properties...
17:39:46 [hsolbrig]: holger: algorithm would have to collect inherited properties. It is implementable...
17:40:13 [hsolbrig]: aryman: I'm not a fan of closed shapes. We expect a more open environment
17:40:39 [ericP]: i think we should ignore "CLOSED" annotations when inheriting. the alternative doesn't provide much value.
17:41:07 [Arnaud]: PROPOSED: Close ISSUE-24, stating that specialization can be achieved via conjunctions
17:41:16 [pfps]: +1
17:41:17 [kcoyle]: +1
17:41:18 [hknublau]: +1
17:41:19 [hsolbrig]: +1
17:41:24 [aryman]: +1
17:41:24 [simonstey]: +1
17:41:26 [ericP]: +1
17:41:28 [Dimitris]: +1
17:41:31 [Labra]: 1
17:41:35 [michel]: +1
17:41:44 [Arnaud]: RESOLVED: Close ISSUE-24, stating that specialization can be achieved via conjunctions
17:42:13 [Arnaud]: Issue-1
17:42:13 [trackbot]: Issue-1 -- What inferencing can or must be used? -- open
17:42:13 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/1
17:43:03 [hknublau]: +q
17:43:09 [Arnaud]: ack hknublau
17:43:20 [hsolbrig]: arnaud: Peter's proposal is that we are operating in the RDFS entailment regime. Other proposal is that inverencing occurs prior to the application
17:43:55 [aryman]: q+
17:43:56 [Dimitris]: +q
17:44:07 [hsolbrig]: holger: Two ways first is core features we have control over. If value type is person, male person and female person are also valid. I'm in favor in walking subclass of rel here
17:44:47 [hsolbrig]: holger: second cases is that, even if inferencing on db isn't activated, ... need inferencing
17:45:25 [hsolbrig]: holger: general question is what can we expect when writing Sparql queries? We have to tell our users what is the default assumption.
17:45:55 [ericP]: +1 to inferencing being spotty on RDF databases
17:46:06 [Arnaud]: ack aryman
17:46:15 [hsolbrig]: holger: I don't believe that we can rely on db inferencing.
17:46:21 [ericP]: SPARQL itself is defined over a graph
17:46:37 [hsolbrig]: aryman: Agree with holger's conclusion.
17:46:40 [hknublau]: +q
17:47:17 [hsolbrig]: aryman: you can write shapes that do and don't depend on inferencing. Do we need to tag the shape to state requirements, reusing Sparql entailment tags?
17:47:58 [Arnaud]: ack Dimitris
17:48:04 [hsolbrig]: aryman: can get around it w/ things like property paths if inferencing isn't present. Implementations could warn if issues
17:48:51 [ericP]: aryman, do you thnk the use cases favor entailment regines associated with shapes, schemas, invocations, or some combiations thereof?
17:49:13 [pfps]: q+
17:49:19 [hsolbrig]: Dimitris: I don't rely on inferencing, I do it through SPARQL. RDFS entailment is hard to do with property paths. I'd be in favor of type entilment only?
17:49:21 [Arnaud]: ack hknublau
17:49:41 [hsolbrig]: hknoblau: Favor specifying inference requirements
17:50:33 [hsolbrig]: hknoblau: no way to tell whether remote sets have inferencing on. What to do when some do, some don't, etc.
17:50:47 [Arnaud]: ack pfps
17:51:11 [hsolbrig]: pfps: I worry that people will get unpleasant surprises
17:51:31 [hsolbrig]: First is that if inferencing doesn't happen uniformly, folks won't know what is going wrong...
17:52:11 [hsolbrig]: Second, if we do our own entailment regime, they will be even more unpleasantly surprised. Sparql engines are not particularly good here, so I'm reluctant to push the issue...
17:52:16 [aryman]: q+
17:52:45 [Arnaud]: ack aryman
17:52:53 [hsolbrig]: arnaud: First question is whether we are silent or not wrt inferencing. Second is whether any feature can/does depend on inferencing.
17:54:01 [iovka]: +q
17:54:25 [Dimitris]: q+
17:54:27 [hsolbrig]: aryman: you could tag a shape with the entailment needed and the engine could determine whether data source provided.
17:54:28 [Arnaud]: ack iovka
17:55:00 [aryman]: q+
17:55:08 [Arnaud]: ack Dimitris
17:55:24 [ericP]: q+ to say that i suspect that entailment regimes will be more commonly associated with invocations and schemas than shapes
17:55:58 [hsolbrig]: Dimitris: Main problem is class scope and value type. .... would be up to the user to profide inferencing
17:56:00 [Arnaud]: ack aryman
17:57:21 [hsolbrig]: aryman: either you punt it to the application or make it explicit by tagging the shape. For shape reuse (template library) you need to advertise what kind of entailment is required.
17:57:27 [Dimitris]: s/.../these could be by default transitive (using property paths) and leave everything else open to the user to run or not inferencing before the validation/
17:57:46 [Arnaud]: ack ericP
17:57:46 [Zakim]: ericP, you wanted to say that i suspect that entailment regimes will be more commonly associated with invocations and schemas than shapes
17:58:26 [hsolbrig]: ericp: Lowest hanging fruit would be to say whatever triples happen to be there. 1.1 advertises what is there, but Sparql is just in terms of triples
17:58:36 [pfps]: doesn't the proposal edited by Holger do subclass transitive closure and distribution over instance of?
17:58:52 [pfps]: q
17:58:56 [pfps]: q+
17:58:56 [hknublau]: pfps: yes
17:59:45 [hsolbrig]: arnaud: So you are saying we'd be silent about it? Wouldn't that lead to unpleasant surprises?
18:00:05 [hsolbrig]: eric: yes. We didn't worry about for several years in Sparql
18:00:08 [Arnaud]: ack pfps
18:00:47 [ericP]: i think that's more the previous issue, inheritance of shapes
18:01:04 [hsolbrig]: pfps: If I write a constraint against person and another against student. It matters to me whether person matters against student. I need to know what kind of reasoning is going on
18:01:23 [ericP]: less about wheather the data has a DL, RDFS, etc. closure
18:01:47 [hknublau]: +q
18:01:48 [ericP]: i think we have to gather use cases
18:01:52 [Arnaud]: ack hknublau
18:02:35 [hsolbrig]: holger: I propse make subclassOf inferrencing mandatory and also for the value type. For all other cases, should be indicated by pointing to entailment URI
18:02:50 [pfps]: the problem with Holger's proposal is that it is defining a new entailment regime
18:02:55 [hsolbrig]: arnaud: new entailment regime?
18:03:00 [iovka]: +q
18:03:07 [hsolbrig]: holger: That is what users expect.
18:03:15 [aryman]: q+
18:03:40 [iovka]: q-
18:03:42 [hsolbrig]: pfps: One may not like rdfs class entailment, but to do something different is "quite brave"
18:03:51 [Arnaud]: ack aryman
18:04:47 [hsolbrig]: aryman: Having the SPARQL engine do the entailment is a 'slippery slope', as any implementation would have to have a reasoner in it. If users expect subclass entailment to be on, it should on in all contexts including normal queries
18:05:11 [hknublau]: +q
18:05:20 [Arnaud]: ack hknublau
18:05:27 [hsolbrig]: aryman: We should leave entailment to the database and work with what we get.
18:08:41 [hsolbrig]: holger: we can specify type inference with rdfs:subclassOf * and let the implementation handle it.
18:10:15 [hsolbrig]: aryman: Concepts are "What is the meaning of value type?" which refers to rdfs:subclassOf and "What is the scoping?" which refers to triples of a proper type. Raw value type / raw scope plus inferred value type / preferred scope
18:10:36 [hsolbrig]: arnaud: aryman and holger to go offline and craft a proposal
18:10:51 [simonstey]: +1 to that proposal
18:10:58 [Dimitris]: +1
18:11:58 [aryman]: q+
18:12:01 [hsolbrig]: pfps: I think it is a bad solution, but we have to live with what the Sparql group produced. Proposal to signal what is required would be better
18:12:05 [Arnaud]: action: aryman to draft a proposal for ISSUE-1 (with Holger)
18:12:05 [trackbot]: Created ACTION-26 - Draft a proposal for issue-1 (with holger) [on Arthur Ryman - due 2015-05-27].
18:12:13 [Arnaud]: ack aryman
18:14:37 [aryman]: probably makes more sense to call the "inferred" variants sh:valueSuperType and sh:scopeSuperType
18:14:37 [hsolbrig]: arnaud: Issue 31
18:14:45 [Arnaud]: issue-31
18:14:45 [trackbot]: issue-31 -- Is there going to be a single unitary semantics for all of SHACL -- open
18:14:45 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/31
18:16:11 [hsolbrig]: arnaud: How will we define things that aren't covered by SPARQL?
18:16:11 [hknublau]: +q
18:16:21 [Arnaud]: ack hknublau
18:16:53 [aryman]: q+
18:16:56 [pfps]: q+
18:16:56 [hsolbrig]: holger: Depends on whether we identify ... Solution is to write templates for them and be done with it.
18:17:02 [Arnaud]: ack aryman
18:17:31 [hsolbrig]: aryman: for things that have a direct Sparql translation we use it, but at some point we need to define what the engine is doing.
18:18:01 [hsolbrig]: aryman: answer should be "yes" to one semantics. Should be a direct translation from compact to verbose
18:18:34 [hsolbrig]: aryman: It is conceivable that compact syntax may not be able to represent all SHACL
18:18:55 [Labra]: q+
18:19:00 [Arnaud]: ack pfps
18:19:10 [hsolbrig]: aryman: should focus on verbose RDF and meaning of compact is derived by translation.
18:20:50 [Arnaud]: ack Labra
18:20:53 [hsolbrig]: pfps: I'm in favor of a single unitary semantics, but it doesn't have to all be Sparql. That there is a single definition of what everything means is what I want.
18:21:29 [hsolbrig]: Labra: I agree with aryman that we need abstract syntax.
18:21:50 [hknublau]: Why?
18:22:24 [hknublau]: We already have a Turtle file with all terms.
18:22:46 [ericP]: pfps, why did OWL define an abstract syntax?
18:22:51 [pfps]: Yes, why is an abstract syntax required? Isn't it enough to have an RDF-encoding and a definition of which RDF graphs are valid SHACL?
18:23:29 [aryman]: q+
18:23:40 [pfps]: OWL had an abstract syntax for two reasons, I think - it was hard to figure out what the RDF syntax should be and lots of people disliked RDF
18:23:41 [Arnaud]: ack aryman
18:23:48 [hsolbrig]: Labra: most languages have an abstract syntax...
18:24:32 [hsolbrig]: aryman: it is possible to define a language without abstract syntax. We can use RDF Turtle, but we need an additional abstraction that corresponds to the meaning.
18:24:58 [hsolbrig]: Labra: I don't mean ShEx necessarily when I say abstract syntax
18:26:36 [aryman]: q+
18:26:36 [hsolbrig]: pfps: There may have been a proposal for two semantics -- on Sparql based and one model theoretic based with overlap.
18:26:42 [Arnaud]: ack aryman
18:28:13 [hsolbrig]: aryman: When you are defining a shape, there is a Sparql query where no bindings say pass, and bindings say fail. The other part is the scoping chunk, where do I go next. We state a binding to a vocabulary ... chunk meanings, but putting it together requires a higher order abstraction
18:28:40 [hsolbrig]: (why did zakim inject elipses into my note?)
18:29:32 [hsolbrig]: pfps: Non-unitary but single semantics. Each part of the semantic puzzle was governed by one emperor, never condiminums...
18:30:06 [Arnaud]: PROPOSED: Close ISSUE-31, agreeing that we will only have one single governing semantics for all of SHACL
18:30:29 [hknublau]: +1
18:30:48 [hsolbrig]: emperor semantics paradigm
18:31:20 [hsolbrig]: how about "non-overlapping" semantics
18:31:31 [aryman]: +1
18:31:32 [ericP]: +1
18:31:33 [simonstey]: +1
18:31:34 [hsolbrig]: +1
18:31:35 [kcoyle]: +1
18:31:36 [Labra]: +1
18:31:54 [iovka]: +1
18:31:54 [pfps]: +1
18:32:10 [Arnaud]: RESOLVED: Close ISSUE-31, agreeing that we will only have one single governing semantics for all of SHACL
18:32:31 [hsolbrig]: break for 15 minutes. Reconvene at x:47
18:32:32 [Arnaud]: break 15mn
18:33:07 [hknublau]: I think I’ll crash now - thanks everyone.
18:33:13 [hknublau]: hknublau has left #shapes
18:47:40 [Arnaud]: back
18:51:15 [ericP]: scribenick: ericP
18:51:18 [Arnaud]: issue-45
18:51:18 [trackbot]: issue-45 -- Should SPARQL be a built-in extension language -- open
18:51:18 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/45
18:51:43 [aryman]: q+
18:51:50 [ericP]: Arnaud: i think we know holger's position on this. we can discuss it wtihout him
18:52:00 [Arnaud]: ack aryman
18:52:01 [kcoyle]: q+
18:52:17 [ericP]: ... his proposal is that SPARQL should be a built-in SHACL extension language
18:52:46 [ericP]: aryman: my colleageue, anamitra, want to use SHACL client-side
18:53:14 [iovka]: +q
18:53:19 [ericP]: ... his user population is conversent with javascript and claims that forcing them to learn SPARQL would be a show-stopper
18:53:52 [ericP]: ... he wants shapes with high-level concepts, but with javascript extensions
18:54:12 [ericP]: ... SPARQL has a special role; specifyig the semantics
18:54:24 [ericP]: ... but that doesn't mean that the implementation has to be SPARQL
18:54:43 [ericP]: ... we should provide language bindings.
18:55:12 [ericP]: ... the core spec should define a language binding for SPARQL, i.e. what's the contract, what's SPARQL return, etc.
18:55:34 [ericP]: ... but we should leave the door open for other langauges
18:56:11 [ericP]: ... plugging in SPARQL should play by the ssame rules as other languages.
18:56:54 [iovka]: q-
18:57:00 [Arnaud]: ack kcoyle
18:57:10 [ericP]: Arnaud: two questions:is SPARLQ the only extension language (arnaud says "no"),
18:57:23 [ericP]: ... .. is SPAQRL mandatory?
18:57:50 [ericP]: kcoyle: i've got the impression from holger that you're not a complete SHACL impl without SPARQL
18:58:05 [ericP]: Arnaud: we can update the text to clarify what we interpret
18:58:31 [ericP]: ... my reading is that he's not requiring that SPARQL be the only extension language
18:58:41 [ericP]: kcoyle: it comes down to whether SPARQL is required
18:58:55 [ericP]: Arnaud: here i'm not sure what he's proposing.
18:58:59 [iovka]: q+
18:59:21 [Arnaud]: ack iovka
18:59:42 [ericP]: iovka: requiring that everyone implement SPARQL is too heavy.
19:00:31 [ericP]: hsolbrig: the proposal said that "SHACL SHOULD include SPARQL as an extension langauge"
19:00:50 [ericP]: ... i want to implement SHACL Core without SPARQL
19:00:55 [Arnaud]: PROPOSED: SHACL shall include SPARQL as an extension language, without making a required feature for compliance (possibly via profiles) and without implying that SHACL must be implemented in SPARQL
19:01:02 [ericP]: ... SPARQL is an obvious extension langauge
19:01:07 [simonstey]: +1
19:01:10 [aryman]: +1
19:01:20 [ericP]: ... i don't know if "SHOULD" means i have to buid one.
19:01:21 [kcoyle]: +1
19:01:25 [hsolbrig]: hsolbrig has joined #shapes
19:01:25 [iovka]: +1
19:01:35 [ericP]: +1
19:01:45 [Labra]: +1
19:01:56 [hsolbrig]: is there any way to see history now that I'm rejoined?
19:02:03 [hsolbrig]: I can't see the proposal
19:02:41 [hsolbrig]: +1
19:03:13 [ericP]: Arnaud: holger has been making the core as small as possible and saying that the core without SPARQL isn't very useful
19:03:37 [ericP]: ... i expect some pushback on that; that we'll have to extend the Core
19:03:53 [iovka]: we had a message he quit 20:56
19:04:27 [Arnaud]: RESOLVED: Close Issue-45, stating that SHACL shall include SPARQL as an extension language, without making a required feature for compliance (possibly via profiles) and without implying that SHACL must be implemented in SPARQL
19:04:29 [Dimitris]: +1
19:04:38 [Labra]: +1
19:04:40 [kcoyle]: +1
19:04:43 [iovka]: +1
19:04:50 [ericP]: -7
19:04:59 [Arnaud]: s/making a request/making it a request/
19:05:16 [aryman]: +1
19:05:30 [aryman]: @ericP huh?
19:05:34 [ericP]: s/-7//
19:06:05 [ericP]: @aryman we weren't supposed to be voting at that moment 'cauuse it was listed as a RESOLUTION.
19:06:27 [aryman]: oops
19:06:51 [hsolbrig]: heck, I'll vot for anything...
19:06:56 [hsolbrig]: +1 for aryman
19:07:02 [aryman]: vote early, vote often
19:07:53 [simonstey]: hello?
19:07:55 [ericP]: kcoyle: why's ISSUE-42 needed?
19:08:05 [Arnaud]: issue-42
19:08:05 [trackbot]: issue-42 -- Adding sh:notEqual to potential datatype properties? -- open
19:08:05 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/42
19:08:25 [pfps]: pfps has joined #shapes
19:08:36 [ericP]: simonstey: the NE came up when i was talking about property paths.
19:08:47 [ericP]: ... so i'm not so sure about ISSUE-42 either
19:09:02 [ericP]: ... i'm more interested in ISSUE-41 Property Paths
19:09:13 [Arnaud]: issue-41
19:09:13 [trackbot]: issue-41 -- Using property paths to refer to values/types? -- open
19:09:13 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/41
19:09:49 [ericP]: ... this came up because i thought that when i define a shape i may want to have the vale of one property have the same value as another property
19:10:13 [ericP]: ... today the OR piece came up indirectly when we were were talking about semantics
19:10:20 [Dimitris]: +q
19:10:33 [ericP]: ... and some low-level inferencing using property paths.
19:10:56 [ericP]: ... i tried to motivate this with use case 43, which is a use case we have at siemens
19:11:25 [ericP]: ... we have heterogeneous models and an intersecting "weaving" model
19:11:46 [ericP]: ... e.g. on the left a cable, on the right a connection, and a cable-to-connection
19:11:49 [Dimitris]: q-
19:12:03 [Arnaud]: https://www.w3.org/2014/data-shapes/wiki/User_Stories#S43:_Using_Property_Paths_for_Property_Value_Comparison
19:12:08 [ericP]: ... so the speed of the left must match the right
19:12:54 [ericP]: ... ISSUE-41 and ISSUE-42 could be reallized with a SPARQL query
19:12:59 [iovka]: +q
19:13:15 [ericP]: ... the question was whether we want to have property paths as a first class member of the language
19:14:05 [ericP]: ... one issue: what if you get more than one term from the property path:
19:14:20 [Arnaud]: ack iovka
19:14:30 [ericP]: ... ..: i propose that if all pass, then the property path passes
19:14:44 [ericP]: iovka: i see two requirements:
19:14:49 [ericP]: ... .. property paths
19:14:53 [ericP]: ... .. comparing values
19:15:02 [pfps]: +1 to iovka - there are two things here - paths and comparisons
19:15:43 [ericP]: simonstey: i agree that these are captured by queries
19:15:48 [pfps]: Why restrict property paths to be parts of a comparison? You might want to count the fillers of a property path or state that they are all in some class.
19:15:52 [ericP]: ... just wondered if we wanted this in the Core
19:16:50 [ericP]: Arnaud: ericP said earlier that there's nothing in SHACL for comparing values, but there is some demand
19:17:02 [iovka]: +q
19:17:07 [Arnaud]: ack iovka
19:17:08 [ericP]: ... putting it in the core, we wouldn't have to fall back to extensions
19:17:25 [ericP]: iovka: i'm wondering how you can include this in the core
19:18:24 [ericP]: ... if computational complexity and intuitive complexity are issues, you don't want variables
19:18:25 [aryman]: q+
19:19:07 [ericP]: simonstey: i used sh:hasValue to say that the property from the focus node ...
19:19:16 [hsolbrig]: +q
19:19:34 [pfps]: q+
19:19:36 [ericP]: iovka: the variable is ?this, which i agree is a simple variable
19:20:24 [ericP]: ... if the bound variable is ?this (the focus node), ...
19:22:16 [ericP]: ... this requires some consideration
19:22:31 [Arnaud]: ack aryman
19:22:49 [ericP]: simonstey: in the req, i said that i need this for S44 Self-referencing
19:23:08 [ericP]: aryman: if you're constraing the value of some predicate, you have two possible sets of results
19:23:41 [ericP]: ... you specify what if hasValue has multiple values, but what if speed is multiple values?
19:23:55 [ericP]: simonstey: haven't thought that one throug
19:24:14 [ericP]: aryman: there are lots of permutations
19:24:29 [Arnaud]: ack hsolbrig
19:24:45 [ericP]: simonstey: i'm fine leaving it to SPARQL; i just wanted to start the discussion
19:24:56 [ericP]: hsolbrig: we had earlier discussions of recursion.
19:25:21 [ericP]: ... when you combine these, you get some interesting features
19:25:35 [aryman]: q+
19:25:53 [Arnaud]: ack pfps
19:26:02 [ericP]: ... when you include paths, you end up with recursion issues like the left-hand-side passes as long as the right-hand-side fails
19:26:20 [ericP]: pfps: i'm mytified by the weaping and gnashing of teath
19:26:51 [ericP]: ... have property paths in SPARQL
19:27:14 [ericP]: ... there are lots of syntaxes that don't use variables
19:27:37 [ericP]: ... as far as comparison goes, SPARQL uses variables but we don't need them.
19:27:59 [ericP]: ... if i want to say that my birth-date is less than my death-date
19:28:14 [ericP]: ... .. there's no problem
19:28:31 [ericP]: ... there's no cognitive load if folks don't use them
19:28:55 [ericP]: ... as far as computational expressivity, it's all expressible in SPARQL
19:28:57 [ericP]: q+
19:29:50 [Arnaud]: ack aryman
19:30:09 [ericP]: q+ to say that judging computational complexity by whether it's implementable in SPARQL is at odds with the notion that we don't ahve to implement in SPARQL
19:30:36 [ericP]: aryman: since this isn't referring to antoehr shape so i don't think it complicates recursion
19:30:49 [Dimitris]: +q
19:30:57 [ericP]: hsolbrig: ok, i will withdraw my concearn
19:31:00 [Arnaud]: ack ericP
19:31:00 [Zakim]: ericP, you wanted to say that judging computational complexity by whether it's implementable in SPARQL is at odds with the notion that we don't ahve to implement in SPARQL
19:32:06 [pfps]: increases the computational complexity of the *core* but not of SHACL
19:32:15 [Arnaud]: ack Dimitris
19:32:24 [ericP]: pfps, ok, i agree with that
19:32:33 [ericP]: but not sure it's relevent
19:33:20 [ericP]: Dimitris: this can be easily expressed in SPARQL but it may affect the cost of non-SPARQL implementations
19:33:38 [ericP]: Arnaud: this will always be true with we add stuff to Core
19:34:13 [ericP]: ... i think questions like this have to be address on a case-by-case basis
19:34:30 [ericP]: ... i'm actually on TC-39 (ecmascript)
19:34:49 [ericP]: ... this is how they proceed with the evolution of ecmascript
19:35:30 [ericP]: ... people come with proposals and the committee pokes holes and if it works, include it in the next version
19:36:09 [ericP]: ... so is it fair to say that NE is dependent on property paths?
19:36:42 [ericP]: simonstey: i said that this is implemented in property paths, but you could implement it other ways
19:36:52 [hsolbrig]: q+
19:37:07 [Arnaud]: ack hsolbrig
19:37:08 [aryman]: leave it open, let Simon develop the semantics
19:37:42 [ericP]: hsolbrig: i'm not sure we should rate the value of a proposal based on the tenacity of the proponent
19:38:14 [ericP]: ... should we add this to the test suite as a conditional proposal, allowing implementers to try it and evaluate it.
19:38:52 [pfps]: +1 to kicking the can down the road
19:39:08 [kcoyle]: alright
19:39:27 [ericP]: topic: ISSUE-42 Not Equal
19:40:28 [ericP]: simonstey: we have maxexclusive/minexclusive properties like in other constraint langages like OCL, you can say that a property shouldn't have a certain value
19:40:49 [pfps]: well, /= can be done in SPARQL so it is in SHACL
19:41:11 [Dimitris]: +q
19:41:20 [Arnaud]: ack Dimitris
19:41:20 [iovka]: +Q
19:41:22 [aryman]: q+
19:41:45 [Arnaud]: ack iovka
19:42:11 [pfps]: you can do /= without dropping into SPARQL, but it is just klunky
19:42:18 [ericP]: Dimitris: we have something like that in OWL saying that properties don't have the same value
19:43:02 [ericP]: iovka: i don't think it's complex to have in the core. if we can test if X has a value, X doesn't have a value is the same thing
19:43:27 [ericP]: ... are we saying that two properties have different values?
19:43:36 [Dimitris]: +q
19:43:40 [Dimitris]: q-
19:44:20 [ericP]: simonstey: i though that we could re-use hasValue both for constants and for the object of property paths
19:44:43 [ericP]: ... but if we don't have property paths, it would just be comparison with a constant
19:44:51 [Arnaud]: ack aryman
19:44:55 [pfps]: saying /= 5.5 is the same as <5.5 or >5.5
19:45:03 [ericP]: iovka: so this doesn't add complexity
19:45:08 [ericP]: simonstey: agreed
19:45:33 [pfps]: don't we already have comparison operators (against constants)
19:45:45 [ericP]: Arnaud, why don't we add EQ, NE, LT, GT?
19:46:04 [ericP]: pfps, i thought we already had all the XS Facets
19:46:13 [ericP]: pfps: i thought we already had all the XS Facets
19:46:36 [Arnaud]: s/Arnaud,/aryman:/
19:46:56 [ericP]: ... for all XSD datatypes, you can define EQ in terms of other types
19:47:07 [Dimitris]: +q
19:47:36 [Arnaud]: ack Dimitris
19:47:42 [ericP]: ... XML 1.1 allows every Unicode character except 0
19:48:00 [simonstey]: +q
19:48:07 [ericP]: Dimitris: does it make sense to add negation?
19:48:23 [Arnaud]: ack simonstey
19:48:57 [ericP]: simonstey: i thought about adding negation to accomplish the same thing, but thought that adding negation would have wider impact on other constructs
19:48:59 [aryman]: q+
19:49:07 [ericP]: ... but sure, we could use negation in other situations
19:49:15 [ericP]: ... and we have troubles with recursion etc.
19:49:20 [Arnaud]: ack aryman
19:49:22 [ericP]: ... it will have some side effects
19:49:57 [iovka]: +q
19:49:58 [ericP]: aryman: given that property paths can have multiple values, it might be better to call it "IN" and "NOT IN"
19:50:24 [ericP]: simonstey: sure
19:50:41 [ericP]: Arnaud: does SPARQL give uus the answer?
19:50:49 [ericP]: aryman: quuestin of where you draw the line
19:51:16 [Arnaud]: ack iovka
19:51:21 [pfps]: +1 to using SPARQL syntax where appropriate
19:51:23 [ericP]: Arnaud: buut in terms of naming, we can stay close to SPARQL
19:51:36 [ericP]: iovka: we considered this in ShEx
19:51:43 [aryman]: q+
19:52:22 [ericP]: ... testing against a particular value is easy
19:52:26 [Arnaud]: ack aryman
19:52:28 [ericP]: ... the syntax will be more complex
19:52:54 [ericP]: aryman: in ResourceShape, there were allowedValues which took allowedalue
19:53:09 [iovka]: +q
19:53:25 [ericP]: ... so in a sense we already have that property so you just use a property path rather than a set of values
19:53:26 [Arnaud]: ack iovka
19:53:27 [simonstey]: sh:allowedValues Enumeration of allowed values
19:53:35 [ericP]: ... did that make it to Holger's spec?
19:54:19 [simonstey]: http://w3c.github.io/data-shapes/shacl/#sparql-AbstractAllowedValuesPropertyConstraint
19:54:44 [ericP]: iovka: this are two different things. one is constants, one from the graph.
19:54:46 [simonstey]: http://w3c.github.io/data-shapes/shacl/#AbstractAllowedValuesPropertyConstraint
19:55:00 [ericP]: aryman: i'm saying we may have the equivalnet of hasValue
19:56:36 [aryman]: sh:allowedValues is similar to sh:hasValue but probably better to keep them separate
19:57:28 [ericP]: topic: tomorrow
19:57:58 [ericP]: Arnaud: propose first hour to talk about UC&R and test suite
19:58:13 [ericP]: aryman: i'd like to see some concrete process on the test suite
19:59:05 [michel]: michel has joined #shapes
20:00:24 [Arnaud]: trackbot, end meeting
20:00:24 [trackbot]: Zakim, list attendees
20:00:24 [Zakim]: sorry, trackbot, I don't know what conference this is
20:00:32 [trackbot]: RRSAgent, please draft minutes
20:00:32 [RRSAgent]: I have made the request to generate http://www.w3.org/2015/05/20-shapes-minutes.html trackbot
20:00:33 [trackbot]: RRSAgent, bye
20:00:33 [RRSAgent]: I see 1 open action item saved in http://www.w3.org/2015/05/20-shapes-actions.rdf :
20:00:33 [RRSAgent]: ACTION: aryman to draft a proposal for ISSUE-1 (with Holger) [1]
20:00:33 [RRSAgent]: recorded in http://www.w3.org/2015/05/20-shapes-irc#T18-12-05