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