Dear all, The current ShEx spec ( http://shex.io/shex-semantics/ ) doesn't say explicitly what is the semantics of recursive shapes when checked against recursive data, as pointed out by Peter's issue ( https://github.com/shexSpec/shex/issues/84 ). Note that the test suite ( https://github.com/shexSpec/shexTest ) contains test cases for the above mentioned situation and implicitly disambiguates the semantics ( see https://github.com/shexSpec/shex/issues/84#issuecomment-375603041 for a list of such test cases). All implementations that pass the tests are thus correct with that respect. We are preparing a fix of the spec in which the semantics of recursive schemas against recursive data will be defined explicitly. The fix will come within two weeks. Best regards, Iovka -- Iovka Boneva Associate professor (MdC) Université de Lille http://www.cristal.univ-lille.fr/~boneva/ +33 6 95 75 70 25

The ShEx semantics in http://shex.io/shex-semantics/ is ill-founded. There are many simple cases of recursive shapes where the semantics gets into an infinite loop trying to determine values for satisfies. This is a serious, fundamental flaw in the semantics. The simplest case is just S = :s @:s G = { :x :p :x } m = { ( :x, :s ) } where determining whether G conforms with S with m requires (from Section 5.6.1) checking satisfies(:x,:s,G,m) but the portion of the definition of satisfies in Section 5.3.2 says that this is defined as satisfies(:x,:s,G,m), which is ill-founded. There are also simple ill-founded cases where the recursion is through a triple constraint, such as S = :s { :p @:s } G = { :x :p :x } m = { ( :x, :s ) } Here there is an added step of checking out the triple constraint, whose semantics is given in Section 5.5.2, but here again satisfies(:x,:s,G,m) depends on satisfies(:x,:s,G,m), which is ill-founded. The obvious solution to this problem is to have the semantics of shapeExprRef use the shape map, i.e., change the bit of Section 5.3.2 from "Se is a shapeExprRef and there exists in the schema a shape expression se2 with that id and satisfies(n, se2, G, m)" to "Se is a shapeExprRef to shape id and m(n,id)". The fact that currently the last argument of satisfies is not currently used also strongly points to this as being the obvious way to fix the semantics. This change makes the above two example valid. It also gives an intuitive meaning to negation, making the following valid S = :s { :p @:s } :t NOT @:s G = { :x :p :x } m = { ( :x, :t ) } peter

Dear all, I've answered the issue pointed out by Peter in another mail earlier today, which unfortunately was not posted to the list immediately because of sender's mail mismatch (I didn't send it with the right e-mail address). Peter, the "solution" that you propose here is precisely what I explained to you in private mails earlier this week, and that is what will be made explicit in the spec shortly, as I promised in my other mail to the public-shex list. Anyways, thank you for your careful reading of the ShEx spec. I will let you know when the fix is done and will be happy to have your comments on it. Best regards, Iovka Le Vendredi 23 Mars 2018 13:51 CET, "Peter F. Patel-Schneider" <peter.patel-schneider@nuance.com> a écrit: > The ShEx semantics in http://shex.io/shex-semantics/ is ill-founded. There > are many simple cases of recursive shapes where the semantics gets into an > infinite loop trying to determine values for satisfies. This is a serious, > fundamental flaw in the semantics. > > The simplest case is just > S = :s @:s > G = { :x :p :x } > m = { ( :x, :s ) } > where determining whether G conforms with S with m requires (from Section > 5.6.1) checking satisfies(:x,:s,G,m) but the portion of the definition of > satisfies in Section 5.3.2 says that this is defined as > satisfies(:x,:s,G,m), which is ill-founded. > > There are also simple ill-founded cases where the recursion is through a > triple constraint, such as > S = :s { :p @:s } > G = { :x :p :x } > m = { ( :x, :s ) } > Here there is an added step of checking out the triple constraint, whose > semantics is given in Section 5.5.2, but here again satisfies(:x,:s,G,m) > depends on satisfies(:x,:s,G,m), which is ill-founded. > > The obvious solution to this problem is to have the semantics of > shapeExprRef use the shape map, i.e., change the bit of Section 5.3.2 from > "Se is a shapeExprRef and there exists in the schema a shape expression se2 > with that id and satisfies(n, se2, G, m)" to "Se is a shapeExprRef to shape > id and m(n,id)". The fact that currently the last argument of satisfies is > not currently used also strongly points to this as being the obvious way to > fix the semantics. > > This change makes the above two example valid. It also gives an intuitive > meaning to negation, making the following valid > S = :s { :p @:s } > :t NOT @:s > G = { :x :p :x } > m = { ( :x, :t ) } > > > > peter >

In Section 5.6.4 the ShEx 2.0 specification (http://shex.io/shex-semantics/) says that "A schema MUST NOT contain any shapeExpr SE which has a shape which contains negated references, either directly or transitively, to SE." The usual meaning of having a recursive negated reference would be that there is an odd number of negations on a path from a shape back to itself. So the schema :a { :p NOT @:a } would have an illegal recursive reference but the schema :a { :p NOT @:b } :b { :p NOT @:a } would not. However, the wording of the phrase in the specification is some what unusual and thus its meaning is unclear. peter

[This e-mail is bcc’ed to all public lists of existing W3C Community Groups] Dear participants of W3C Community Groups, Once again, the W3C Community Groups will have the possibility to meet during TPAC2018 which will be held in Lyon, France, at the "Cité Centre de Congrès de Lyon" [1] TPAC 2018 22 - 26 October 2018 Lyon, France https://www.w3.org/2018/10/TPAC/Overview.html We ask you to start discussions within your groups to determine whether and when your group(s) would like to meet during this week. Please complete the following questionnaire by 27 April 2018: https://www.w3.org/2002/09/wbs/1/CGsTPAC2018/ W3C Community Groups can hold 2-hour meetings on Monday, Tuesday, Thursday, Friday. The Available slots will be: 8:30 - 10:30 10:30 - 12:30 13:30 - 15:30 15:30 - 17:30 We will be able to accommodate 4 meetings per day, so 16 over the entire TPAC week. Outside of their Community Group meetings, non W3C-Member CG participants may attend as observers the Working and Interest groups meetings who accept observers, as well as the Technical Plenary Day will be held on 24 October from 08:30-18:00. There will be an early-bird registration fee of EUR 92 + 20% taxes (VAT) per day to offset a portion of the meeting costs. If you have any questions, please contact <w3t-tpregister@w3.org>. For the W3C TPAC 2018 Meeting Team; Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.ccc-lyon.com/home -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/CMercier/

ShEx 2.0 (http://shex.io/shex-semantics/) allows shape schemas like :sl @:sl but this is supposed to only be because this prohibition was inadvertently left out of the document. Does anyone have information that would indicate that this shape schema should not be in ShEx? peter

Hi everyone, Tomorrow's agenda is available here: https://github.com/shexSpec/shex/blob/master/meetings/20180315-agenda.md additions or changes are, as always, welcome! Note: that thanks to Andra, we have a zoom account for the meeting tomorrow (and the following meetings). Thank you again, Andra! Hopefully, this will improve the sound quality of the telcos Best regards, Dimitris -- Kontokostas Dimitris

Regrets for tomorrow’s telecon. Gregg Kellogg gregg@greggkellogg.net > On Mar 14, 2018, at 9:27 AM, Dimitris Kontokostas <jimkont@gmail.com> wrote: > > Hi everyone, > > Tomorrow's agenda is available here: > https://github.com/shexSpec/shex/blob/master/meetings/20180315-agenda.md <https://github.com/shexSpec/shex/blob/master/meetings/20180315-agenda.md> > > additions or changes are, as always, welcome! > > Note: that thanks to Andra, we have a zoom account for the meeting tomorrow (and the following meetings). Thank you again, Andra! > Hopefully, this will improve the sound quality of the telcos > > Best regards, > Dimitris > > -- > Kontokostas Dimitris

I am pleased to announce the release of a ShEx 2.0 implementation in java. The implementation is available on github at this address: https://github.com/iovka/shex-java The implementation supports: - ShExJ parsing and serializing - ShExC parsing - ShExR parsing - checking schema requirement - validation (incremental and refine validation) We welcome any feedbackorquestions you may have. Best Regards, Jérémie Dusart

* Jérémie Dusart <jeremie.dusart@inria.fr> [2018-03-08 11:26+0100] > I am pleased to announce the release of a ShEx 2.0 implementation in java. Congradualations! I bounced this to semantic-web@w3.org so others would see it. > The implementation is available on github at this address: > https://github.com/iovka/shex-java > > The implementation supports: > - ShExJ parsing and serializing > - ShExC parsing Are you using the ANTLR parser that Harold and Jose use? > - ShExR parsing ooo, how do you do parse ShExR? (My impl does recognition by validating against ShExR.shex) > - checking schema requirement > - validation (incremental and refine validation) > > We welcome any feedbackorquestions you may have. Responding to <https://github.com/iovka/shex-java>: | On validation, the current implementation, using RDF4J, passes 1033 tests, fails 3 tests and skips 41 tests. The tests that are skipped are the one with at least one of those traits: | | Start | SemanticAction | ExternalShape | ShapeMap | Greedy I should remove tests with the "Greed" trait; they're from ages ago when we were considering a different algorithm. | relativeIRI Feel free to improve the traits. | Using Jena, more tests are failed because new label are generated for bnode. The same mechanism is also present in RDF4J, but has been disabled in the tests. I'm hoping those all have the trait ToldBNode. Can you confirm? I'd like to know if it's possible to pass some ToldBNode tests by luck. | On negative structure, the current implementation passes all the tests. | | On negative syntax, the current implementation passes 100 out of the 102 tests. Feel free to suggest improvements. > Best Regards, > Jérémie Dusart -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.

Hi Jérémie On Thursday, March 08, 2018 11:27 AM, Jérémie Dusart [mailto:jeremie.dusart@inria.fr] wrote: > I am pleased to announce the release of a ShEx 2.0 implementation in java. Great! I've been looking for this. > > The implementation is available on github at this address: > https://github.com/iovka/shex-java > > The implementation supports: > - ShExJ parsing and serializing > - ShExC parsing > - ShExR parsing > - checking schema requirement > - validation (incremental and refine validation) > > We welcome any feedback or questions you may have. I cloned the GH repository and made a naïve mvn clean install on but the build won't complete since some test cases throws failures. It seems that at least TestShExCParserShExJSerializer looks for a file /shexTest/validation/manifest.ttl that's not part of the distribution. Is there some magic going on behind the scenes or am I simply doing something wrong? Configuration: Windows 7 Maven 3.5.2 Java 1.8.0_112 Thanks, Lars