Re: On the inevitability of SPARQL/SPIN for SHAQL

On Sun, Mar 1, 2015 at 9:56 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

>
> On 3/1/15 5:24 PM, Jose Emilio Labra Gayo wrote:
>
>> 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 looks like it would simply reinvent a new SPARQL, only that no
> existing tool would support it yet.


No, it is leveraging on XPath which has lots of implementations and tools.
Maybe, the syntax can be "CONSTRAINT" instead of "FILTER" to clarifiy that
it is not SPARQL.

<RectangleShape> { :weidth ?w, :height ?h, :area ?a, CONSTRAINT (?w * ?h =
?a) }

The only neede feature is to associate variables with the objects that are
being matched and to have a "CONSTRAINT <XPath-Expr>" that evaluates to a
boolean.

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.
>>
>
> Why not?


Because  you are embedding SPARQL in the generation of human-readable
messages.

If someone wants to use another language, then this would also have a
> mechanism to create strings. JavaScript certainly has.


And in that way, the shapes generating human-readable messages in SPARQL
are not compatible with the shapes generating human-readable messages in
Javascript.


> And even if not, the human-readable messages are purely optional anyway,
> but preventing something that is already solved by SPARQL doesn't sound
> like a good idea.


Because we are using SPARQL for something that is not needed.

And I emphasize, I am not against SPARQL, I am against embedding SPARQL in
an uncontrolled way what is supposed to be a high-level language.

Best regards, Labra



>
> Holger
>
>
>


-- 
-- Jose Labra