Re: Suggested redesign of Operations section

On 9/25/2015 7:59, Arthur Ryman wrote:
> Holger,
>
> Defining the semantics of the SHACL language in terms of Java code is
> too low level. To really understand what the code does, one would have
> to understand every Java class involved, not just a few snippets. We
> should aim to describe the meaning of SHACL programs in clear, high
> level terms.

In that case, we would have to drop the whole Operations section and 
leave the prose for the details. The description of sh:hasShape would 
have to be ramped up considerably.

And: could we please stop using the term "SHACL programs"? This is IMHO 
misleading as SHACL is not a programming language, and we already have 
the term "shapes graphs" for that concept.

Holger


>
> -- Arthur
>
> On Tue, Sep 8, 2015 at 3:29 AM, Holger Knublauch <holger@topquadrant.com> wrote:
>> In the current draft, section 10 defines several entry points that SHACL
>> systems should be able to handle - operations to validate a given graph or a
>> given node. I have so far used pseudo-code that is ambiguous, hard to test
>> and hard to understand.
>>
>> I am suggesting to use a Reference Implementation using real, executable
>> Java code instead of pseudo-code. I have attached the current design of the
>> main class of that API that does the control logic (just excluding SPARQL
>> execution). The spec would include key snippets such as the following,
>> together with documenting prose:
>>
>>
>>      void validateGraph(String minSeverity) {
>>          for(Node shape : getAllInstances(iri(SH.Shape), shapesGraph)) {
>>              validateShape(shape, minSeverity);
>>          }
>>      }
>>
>>      void validateShape(Node shape, String minSeverity) {
>>          for(Node focusNode : getNodesInScopeOfShape(shape)) {
>>              validateNodeAgainstShape(focusNode, shape, minSeverity);
>>          }
>>      }
>>
>>      boolean validateNodeAgainstShape(Node focusNode, Node shape, String
>> minSeverity) {
>>          boolean hasResults = false;
>>          if(isNodeValidForFilterShapes(focusNode, shape)) {
>>              for(Node constraint : getConstraintsOfShape(shape)) {
>>                  if(hasMinSeverity(constraint, shape, minSeverity)) {
>>                      if(isNodeValidForFilterShapes(focusNode, constraint)) {
>>                          hasResults |=
>> validateNodeAgainstConstraint(focusNode, constraint, shape);
>>                      }
>>                  }
>>              }
>>          }
>>          return hasResults;
>>      }
>>
>> This API is actually executable but is implemented against a very simple
>> platform-neutral API with interfaces Node, Triple, Graph and Dataset. As a
>> proof-of-concept, I have implemented those interfaces against Jena and now
>> have a new engine implementation that passes all test cases. A port to other
>> libraries such as Sesame or even other languages like JavaScript should be
>> trivial. Note that the API has been designed for conceptual clarity instead
>> of performance.
>>
>> My proposal is to rewrite section 10 based on this redesign.
>>
>> Thanks,
>> Holger
>>

Received on Thursday, 24 September 2015 22:41:02 UTC