Re: On the inevitability of SPARQL/SPIN for SHAQL

ARQ (and hence, SPIN) use a lot of the xpath functions in various sensible
place (filter, bind).  xpath certainly seems like a good place to go for
your built-in function vocabulary.  I like to idea of being able to extend
this (as TopBraid does), but I don't know if there is a way to standardize
the extensions.

If that is what you are proposing, then I think I find myself in violent
agreement; we should certainly use the function set from XPath for Shapes -
no sense in re-inventing that, and we certainly need a function vocabulary.



Dean


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

> Jose,
>
> I do not understand what you are proposing - how exactly you propose to
> use XPath, what do you mean by 'controlled way' and so on.
>
> I feel these ideas are too vague and confusing to have an effective
> conversation about.
>
> Irene
>
> On Mar 1, 2015, at 3:57 PM, Jose Emilio Labra Gayo <jelabra@gmail.com>
> wrote:
>
> On Sun, Mar 1, 2015 at 5:03 PM, Dean Allemang <
> dallemang@workingontologist.com> wrote:
>
>> While I am a big fan of XPath (I use it all the time), I have to agree
>> with Irene here - treating RDF as if it were XML seems like a bad idea.
>>
>
> As I said in my previous email. My proposal was to use the same subset of
> XPath that SPARQL is using in the FILTER expressions so the Shacl language
> can define constraints that involve arithmetic and string operations in an
> easy and controlled way.
>
> I can't help but think that there is a perception thing going on.  The
>> resistance to committing to SPARQL as a constraint language in favor of,
>> e.g., XPath,
>>
>
> I think there is a misconception in that phrase. In fact, if we use SPARQL
> we will also use the same subset of XPATH. My proposal was to use only that
> subset as predefined builtin expressions...
>
> seems to stem from a feeling that SPARQL is a low-level,
>> implementation-specific language whereas some alternative is higher-level.
>>
>> I view SPARQL as being at a much higher level than, e.g., XPath (just as
>> I view RDF as being at a higher level than XML).  In RDF, we talk about how
>> our resources relate to one another - not how a document (or a table, or a
>> spreadsheet, or etc.) happens to structure that relationship.   XPath is a
>> high-level language for navigating a very particular structure; if you
>> change the structure, your XPath is at risk (and many of the features of
>> XPath are there to help you make an XPath expression immune to certain
>> changes in structure).   SPARQL is a language for navigating data graphs,
>> regardless of how they are represented in a document.
>>
>>
>> I think this is the source of a lot of the "XML Confusion" that Irene
>> mentions in her message.  Those of us who are RDF fans can't help but be
>> puzzled by any language proposal that, in our view, makes lower-level
>> commitments in the shapes language.
>>
>
>> I suspect that there are others for whom SPARQL seems like the low-level
>> language.  I can't represent this viewpoint as well since I don't myself
>> hold it.  But if this is the view one is coming from, then committing to
>> SPARQL would seem like a low-level commitment.
>>
>> and I think we are agreed that we expect Shapes to develop a high-level
>> language.  We just don't agree on where the levels are.
>>
>
> Yes, I also want Shapes to be a high level language...that's probably the
> main point that I am trying to defend. If we want to have a high level
> language, we should not embed SPARQL inside it without control.
>
> Best regards, Jose Labra
>
>>
>>
>>
>>
>> Dean
>>
>>
>> On Sun, Mar 1, 2015 at 6:19 AM, 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
>>>
>>> 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
>
>