Re: On the inevitability of SPARQL/SPIN for SHAQL

On Tue, Mar 3, 2015 at 6:40 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

>  On 3/3/2015 15:30, Jose Emilio Labra Gayo wrote:
>
>  On Tue, Mar 3, 2015 at 6:11 AM, Holger Knublauch <holger@topquadrant.com>
> wrote:
>
>>  On 3/3/2015 14:59, Jose Emilio Labra Gayo wrote:
>>
>>
>>
>>> Why should this group take on such undertaking instead of reusing
>>> already existing language produced by W3C?
>>>
>>
>>  Because "SPARQL queries cannot easily be inspected and understood,
>> either by human beings or by machines, to uncover the constraints that are
>> to be respected". [1]
>>
>>
>>  Jose, the sentence following your excerpt above is
>>
>> "The term 'shape' emerged as a popular label for these constraints."
>>
>> I believe this clarifies that the group was not contrasting SPARQL with
>> something like XPath,
>>
>
>  Not at all...why do you say that?
>
>
> Because you were responding to Irene's question that was comparing SPARQL
> with your XPath variant. The quote that you used to defend your view point
> was about something else.
>

I understood Irene's question as why we should not use SPARQL and when I
started to write my answer I noticed that it was already written.

> I think I have already clarified what subset of XPath I was talking about
> and for what purpose.
>
>
>> but rather SPARQL versus the high-level vocabulary of sh:minCount and
>> sh:valueType. A new language such as a yet-to-be-defined variant of XPath
>> or a yet-to-be-defined subset of SPARQL's FILTER expressions would arguably
>> have the same basic characteristics as SPARQL itself.
>>
>
>  No, because that subset of XPath (or SPARQL expressions as Richard said)
> can be used for built-in functions and operations and has a much simpler
> semantics that we can leverage on than the full SPARQL language with BGPs,
> UNIONs, OPTIONALs, etc.
>
>
> SPARQL expressions include EXISTS and NOT EXISTS [1], i.e. you would need
> to define a sub-set of SPARQL expressions here to avoid the features you
> describe.
>
> Sorry, I am not seeing any realistic support for defining such a new
> language for SHACL. It would exclude too many real-world use cases. Your
> goal of "simple semantics" has not been approved, and I don't believe it
> should be approved because it limits the usefulness of the language. As
> Richard stated, such a reduced language would fail on the marketplace.
>

In my opinion that will depend on which language will result. I think most
of the use cases can be captured by a high level declarative language that
people can easily understand.

The remaining complex use cases can be done with the extensibility
mechanism that has already been proposed and that is similar to what you
are proposing. And I have already said that I support it.

There are some use cases that involve arithmetic expressions and string
comparisons that could be handled with the "SPARQL expressions"
subset...but if there is no consensus on that, those use cases could be
solved with the extensibility mechanism.

I think the main difference between your proposal and mine is that I prefer
to define a set of high-level constructs and an abstract grammar for those
that can have a well defined semantics and can be used in a safe and
compatible way by ShACL users, while you prefer to have a minimal
"template" construct which is quite flexible because you can put there
whatever SPARQL definition you want.

Of course, you proposal is more flexible and offers greater expressivity,
but it also has a lot of risks.

It reminds me to the history of programming languages. You can have much
more expressivity if you work in a low level language like Assembler...you
may add macros to assembler so it looks better, but you are still tied to a
particular architecture and you lose compatibility. The other alternative
is to try to define a high level language with a predefined set of well
defined constructs...and maybe some extensibility mechanism were you can
call assembler...but trying to have well-defined boundaries between the
high-level and low-level language offers a lot of advantages that you lose
if you remain in the low-level field.

Best regards, Jose Labra


> Holger
>
> [1] http://www.w3.org/TR/sparql11-query/#func-filter-exists
>



-- 
-- Jose Labra