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

I believe our design philosophy should be: "Simple constraints are
simple to state, complex constraints are possible to state." This
gives us a natural dividing line.

1. SHACL Lite - has a high level vocabulary for common constraints. No
extensibility. No bias towards any implementation technology. The spec
gives the semantics of the common constraints in SPARQL. This implies
we can leverage SPARQL engines for implementations.

2. SHACL Full - has an extension mechanism, but the extensions are
language-dependent. No attempt to define a language-neutral mechanism.
Define vocabulary for SPARQL extensions, and maybe Javascript. Also
provide a way to package extensions so they can be re-used by people
who do not write extensions.

-- Arthur

On Wed, Mar 4, 2015 at 12:25 AM, Jose Emilio Labra Gayo
<jelabra@gmail.com> wrote:
> 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
>

Received on Tuesday, 17 March 2015 22:47:08 UTC