Re: On the inevitability of SPARQL/SPIN for SHAQL

On Sun, Mar 1, 2015 at 3:19 PM, Irene Polikoff <irene@topquadrant.com>
wrote:

> Personally, I feel that mixing paradigms results in design that is
> inelegant and problematic on many levels. This is RDF. Why bring XPath in
> when there are equally good and better approaches within RDF stack?
>
> Besides RDF is still recovering from XML baggage and misunderstandings
> that resulted from people confusing it with its XML serialization.
>
> Irene
>

What I proposed is the possibility to use the same XPATH subset that is
used by SPARQL [1] for the string and arithmetic operations. SPARQL is in
fact using it, so it is not something strange to the RDF stack.

My proposal has nothing to do with RDF/XML serialization.

Best regards, Jose Labra



[1] http://www.w3.org/TR/sparql11-query/#FunctionMapping

>
> Sent from my iPhone
>
> On Mar 1, 2015, at 4:45 AM, Jose Emilio Labra Gayo <jelabra@gmail.com>
> wrote:
>
> 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
>
>


-- 
-- Jose Labra