Re: Suggested redesign of Operations section

Holger,

SHACL is a language, so what should we call a
file/document/graph/resource that conforms to the SHACL language?

Do you consider SPARQL to be a programming language?

-- Arthur


On Thu, Sep 24, 2015 at 6:40 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> 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 Friday, 25 September 2015 18:43:18 UTC