Re: Implementation feasibility

On Mon, Mar 23, 2015 at 1:42 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 3/21/2015 18:36, Jose Emilio Labra Gayo wrote:
>
>> I have identified the different roles of SPARQL vs SHACL in this other
>> email:
>>
>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/
>> 2015Feb/0368.html
>>
>
> In which you contradict yourself in a single paragraph:


> 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.
>
> First you state that you'd prefer if SPARQL was not the *only* language
> for macros. Then later you state that using SPARQL is a mistake. It would
> be helpful to get a clarification on your current opinion about this
> critical question.


I don't see such a contradiction. My opinion remains that there is a need
to have a clear separation of concerns about the use of SPARQL in SHACL.

I said that I have no problem to define part of the semantics of the
high-level language constructs with mappings to SPARQL.

I have no problem to allow an extensibility mechanism where we can call
external SPARQL processors.

I have also no problem to have a language construct to define macros.

What I am against is that the SHACL high-level language depends on a full
SPARQL engine and that one cannot implement it without that engine. So if
we add a language construct to define macros, then that language construct
should not be tied to SPARQL.

I propose is to identify that SHACL high-level language expressive enough
to cover most of the use cases without having to use the extensibility
mechanism for those use cases which would mean that the shapes defined with
one SHACL processor would be incompatible with the shapes defined with
another one.

-- 
-- Jose Labra