Re: “SHACL Minus SPARQL” (was: Re: On the inevitability of SPARQL/SPIN for SHAQL)

On Tue, Mar 3, 2015 at 10:20 PM, Richard Cyganiak <richard@cyganiak.de>
wrote:

> Hi Jose,
>
> > On 3 Mar 2015, at 20:43, Jose Emilio Labra Gayo <jelabra@gmail.com>
> wrote:
> >
> >> But this is a false alternative. The proposal is to have all of the
> above:
> >>
> >> - A single “template” construct that allows the definition of “macros”
> >> - A well thought out library of “core macros” with clear semantics
> >> - [mumble mumble something about recursion]
> >>
> > My proposal is just the opposite...you may call it "SHACL plus  SPARQL"
> if you like:
> >
> > - A single high level language that contains the common constructs for
> RDF validation and has a well defined semantics independent of SPARQL
> > - Some extensibility mechanisms that allows users to express complex
> constraints in SPARQL (or other external language)
> > - Optionally, some construct to define macros if the WG considers them
> necessary.
> >
> > The main advantage is that you obtain a high level language which can be
> optimized and implemented by different technologies.
>
> The claim that this is an advantage of “SHACL Plus SPARQL” is false.


Not, if your template mechanism only allows SPARQL. If you define a generic
template mechanism independent from SPARQL, then that would be equivalent
to my third point. But I think that was not your proposal.

Really, if you think about that, the results can be similar, but I put more
emphasis on the design of a high level language than in the implementation
details. And that's the way to proceed when one is designing a new language
or vocabulary.

Of course, you can take a look to how you implement that, and I am not
opposed to that, even I think we can have default mappings to SPARQL...but
in my proposal I reverse the order...that's why I start with SHACL and then
add SPARQL....


> The “SHACL Minus SPARQL” profile can also be optimised and implemented by
> different technologies.
>

Yes, but that is a profile, not the high level language...maybe, if we
align terminology we could  try to find more points in common:

- Your "SHACL Minus SPARQL" profile could be my "SHACL core language"
- Your template mechanism could be my "macro" definition mechanism if it
were independent of SPARQL and it was defined just as a "macro definition
mechanism".

> You also obtain compatibility between shapes defined in those different
> systems
>
> The claim that this is an advantage of “SHACL Plus SPARQL” is false.
> Shapes defined in the “SHACL Minus SPARQL” profile would also be compatible
> between such different systems.
>

The same as above...you are talking about the profile when I was talking
about the core language...but I really think it will be better for the
users to know what is the core language where they can define their shapes
in a compatible way.

In my opinion, relegating it to be a "profile" when it is the core, high
level language we are planning to define, and giving emphasis to the macro
definition instead of the language is reversing the priorities.

For me, implementing templates with SPARQL is an implementation detail that
can be the choice in SPIN...but I think if we are in w3c WG we are trying
to define recommendations that are don't depend on some particular
technology or implementation. If there was no other approach than SPIN, it
could make sense to go in that direction, but there are already some
alternatives that show that it can be done with a different approach. Why
should this WG prevent them to continue working on that?

> and you can even do some reasoning about shapes like comparing if two
> shapes describe the same RDF graph.
>
> I am not aware that this is a requirement that this working group has
> embraced.
>

I though about adding to add it as a requirement because it is obvious that
if you want to describe RDF you would like to be able to recognize if your
SHAPE description was the same as another SHAPE description. However, I
understood that it could be a difficult to achieve goal in general and I
refrained to add it as a requirement. So, even if this is not a
requirement, I don't see why this feature would be harmful. On the
contrary, having a declarative way to compare and transform shapes can
offer lots of advantages.

> This alternative does not depend on a particular technology (SPARQL +
> mumble mumble something about recursion) and offers more advantages.
>
> The claim that the “SHACL Minus SPARQL” profile depends on a particular
> technology is false. It can be implemented without SPARQL.
>

Maybe you are talking about what you called "SHACL Minus SPARQL" profile
here. But "SHACL Minus SPARQL" as an approach depends on SPARQL because it
says that the templates are defined in SPARQL.

>
> I believe that “mumble mumble something about recursion” is, at the
> moment, a shared feature between both proposals.
>

Yes, and I also think both proposals have lots of things in common.

>
> > What is more, this proposal is even compatible with your proposal,
> because you can implement the high level language using SPARQL + mumble
> mumble…
>
> The “SHACL Plus SPARQL” proposal is not compatible with the “SHACL Minus
> SPARQL” proposal, because the latter proposal offers users of the “SHACL
> Full” language the ability to create SPARQL-based macros, while the former
> proposal doesn’t.
>

My proposal also contains a mechanism to define macros in general.


> > There is no advantage of limiting SHACL to work only on top of SPARQL.
>
> The claim that the “SHACL Minus SPARQL” profile works only on top of
> SPARQL is false. The profile can work on any underlying technology provided
> that a semantics-preserving mapping to SPARQL is available.
>

Here again you are talking about the profile while I am talking about SHACL.


> > I repeat that I have no problem to define the semantics of the high
> level language with mappings to SPARQL, but we should be able to identify
> that high-level language so we can allow other systems to implement it.
>
> In “SHACL Minus SPARQL”, the high-level language is the library of “core
> macros”. I’d be delighted to work on nailing down this set of core
> features,


OK, so I can assume that you don't oppose to start defining the high level
language.

For me there is a difference between a high-level language and a library of
"core macros" But probably we could have an agreement that it can be seen
as an implementation detail.

The end user does not care how the language is implemented, he will only be
interested to know which language features he has to define RDF shapes.

but this is rather difficult as long as one party to the discussion is in
> denial about what the other party is saying.
>

I think my position is quite clear and I am trying to be as constructive as
I can. I am only claiming that we should concentrate on the high-level
language and leave out the implementation details.

And if one party of the discussion is very interested to include those
implementation details in the spec, I would ask them to be in a separate
section at least.

-- 
-- Jose Labra