Re: On the inevitability of SPARQL/SPIN for SHAQL

On Mar 1, 2015 9:24 AM, "Jose Emilio Labra Gayo" <jelabra@gmail.com> wrote:
>
> 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.

Hi Jose,

I think that we are in a point where we need concrete solutions or proof
that your suggestion will be able to handle the requirements

Best,
Dimitris

>
> Best regards, Jose Labra