Re: On the inevitability of SPARQL/SPIN for SHAQL

On Sun, Mar 1, 2015 at 7:57 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

>  On 2/28/2015 19:51, Jose Emilio Labra Gayo wrote:
>
>
> 3.- Define new macros using SPARQL. This is for me the most controversial
> point. I may agree to have some mechanism to define macros in the language,
> but i would not impose those macros to be defined only in SPARQL. If we
> want macros with parameters and so, we can add some language construct to
> define macros. Defining those macros directly in SPARQL is a language
> mistake. It means that the high level language (Shacl) allows users to
> define functions in the low level language (SPARQL). It would be as if Java
> programmers could define their methods using bytecodes.
>
>
> The comparison with Java bytecode is IMHO not appropriate - nobody except
> some extreme geeks would hand-code Java bytecode, while SPARQL is
> sufficiently well established and provides the right level of expressivity.
>

I think it was agreed from the beginnings of this WG and the results of the
RDF Validation workshop that a high level language was needed. In fact it
is one of the first approved requirements. If the high level language
allows to mix expressions in the low level language in an uncontrolled way
then it is not a high level language at all.

As I said, I am not opposed to SPARQL and I really think it can be used in
a controlled way, but I think it will be a design language mistake to allow
templates with embedded SPARQL.

>
> Could you clarify what alternative language constructs to define macros
> you envision? How would you cover the various requirements currently under
> "Complex Constraints" such as string and math operations?
>

There are two possibilities there:

1.- To define those complex constraints using the extensibility mechanism
in a controlled way so the users that define those complex constraints
using SPARQL know that their shapes will not work in an implementation
without SPARQL support.

2.- To allow the core language to have XPATH like functionality and
variables. It can be something similar to the expressions that appear in
the FILTER clauses in SPARQL. As an example using the compact syntax we
could say:

<RectangleShape> { :weidth ?w, :height ?h, :area ?a, FILTER (?w * ?h = ?a) }

This second possibility leverages on the XPath language whose expressions
can be simpler and better understood than the whole SPARQL language.

> 4.- Use SPARQL to construct error messages. I think this is not needed and
> we can just define some vocabulary of error messages or some
> Post-Schema-Validation data structure with information about the errors.
>
>
> I disagree. We have lots of evidence that it is necessary to construct
> human-readable error messages and SPARQL provides the necessary building
> blocks (e.g. a BIND(CONCAT(...) AS ?message) at the end of a WHERE clause.
>

But generating human-readable error messages can be a post-process
operation. Embedding that functionality in SPARQL you are preventing any
implementation that is not based in SPARQL.


> How would a generic post-schema-validation data structure have enough
> information to communicate something like...
>

It depends on what information has the post-schema-validation data
structure and the context in which it is run.

Best regards, Jose Labra