- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 16 Feb 2017 16:54:06 -0800
- To: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
Please provide a pointer to this discussion and any relevant resolutions. Peter F. Patel-Schneider Nuance Communications On 02/16/2017 04:01 PM, Holger Knublauch wrote: > > > On 17/02/2017 9:03, Peter F. Patel-Schneider wrote: >> Some of the syntax requirements for constructs in SHACL-SPARQL hinge on >> whether a string is a syntactically correct SPARQL SELECT or ASK query and are >> thus very complex. There is no distinction in SHACL between these syntax >> requirements and the syntax requirements for constructs in SHACL Core so a >> SHACL Core processor would need to implement a SPARQL syntax checker. >> >> However, I don't see any good reason why a SPARQL Core processor needs to >> consider the syntactic validity of any SHACL-SPARQL constructs at all. A SHACL >> Core processor, by design, doesn't do anything with these construct so there >> is no benefit for a SHACL Core processor to do this checking. >> >> So all that a SHACL Core processor really should be doing as far as syntax >> testing is concerned is checking the SHACL Core constructs for syntactic >> validity. This appears to be fairly easy - the hardest part is probably >> checking for valid SHACL property paths. But even if checking the syntactic >> validity of a SHACL property path is not so easy, a SHACL Core processor is >> going to have to do much of the checking for syntactic validity when it uses >> the list. >> >> It thus seems to me that SHACL Core processors should be required to check for >> syntactic validity of SHACL Core constructs and should completely ignore >> SHACL-SPARQL constructs. > > The WG had already discussed this topic at length and come to the conclusion > outlined in my email, for the reasons outlined in my email. > > Holger > > > >> >> Peter F. Patel-Schneider >> Nuance Communications >> >> >> >> >> On 02/16/2017 01:54 PM, Holger Knublauch wrote: >>> Hi Lars, >>> >>> there are two major reasons for the current wording, basically due to the >>> complexity of the many syntax rules: >>> >>> 1) If we were to make it a MUST then each SHACL implementation would have to >>> implement all the syntax rules, and we as the WG would need to define test >>> cases for all kinds of invalid structures. The SHOULD lowers the barrier of >>> entry and the formal process issues significantly. >>> >>> 2) It would require validation (for well-formedness) of the shapes graph and >>> this is a very expensive operation. In many scenarios such as interactive data >>> entry tools, the shapes graph is identical to the data graph (or at least is >>> part of the imports closure). If you make an edit, then the shapes may become >>> invalid. This means that a validator would have to perform checking of the >>> shapes before each validation, and this is prohibitively expensive in cases >>> like form validation in real time, for each instance. >>> >>> Having said this, many syntax rules can be expressed in SHACL itself. The >>> expectation of the WG is that a meta-schema for SHACL will emerge (e.g. as an >>> open source project) outside of the W3C process. Not everything needs to be >>> done by the WG or the spec. >>> >>> Hope this clarifies it. >>> Holger >>> >>> >>> On 16/02/2017 19:36, Svensson, Lars wrote: >>>> Hello all, >>>> >>>> Section 3.4.2 [1] states that if a shapes graph is ill-formed, the SHACL >>>> processor SHOULD produce a failure. Why is that a SHOULD and not a MUST? Or >>>> put differently: In which cases would it be acceptable for a processor not >>>> to produce a failure when processing an ill-formed shapes graph? >>>> >>>> [1] https://w3c.github.io/data-shapes/shacl/#ill-formed-shape-graphs >>>> >>>> Thanks, >>>> >>>> Lars >>>> >>>> *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** >>> >
Received on Friday, 17 February 2017 00:54:45 UTC