Re: On the inevitability of SPARQL/SPIN for SHAQL

On Tue, Mar 3, 2015 at 12:24 PM, Richard Cyganiak <richard@cyganiak.de>
wrote:

> Jose,
>
> > On 3 Mar 2015, at 04:59, Jose Emilio Labra Gayo <jelabra@gmail.com>
> wrote:
> >
> > I was talking about the same subset of XPath functions that is used in
> the Filter Expressions in SPARQL...as Richard said, you can call it Sparql
> expressions…
>
> What you say is confusing. SPARQL expressions are not a subset of XPath.
> It’s a very different language.
>

> Do you propose that the WG design a new expression language for operating
> over RDF nodes that is an XPath subset?
>

> Or do you propose support for SPARQL expressions as-is?
>

I don't think it is so confusing. I proposed to leverage on the functions
and operators described in section 17 of [1]. The WG can decide if there
are some functions like EXISTS or NOT EXISTS that don't make sense for
SHACL.

My proposal was trying to offer some design alternative that can have a
balance between expressiveness and controlled evaluation.


> > That subset has a simple semantics that we can leverage on and does not
> have the complexity of the full SPARQL.
>
> I’m not sure that I would agree with this statement. A lot of the
> complexity of SPARQL is in the expression language and function library.
>
> This is difficult to quantify, but in my printed copy of the SPARQL spec,
> the chapters describing the various language constructs cover 46 pages. The
> single chapter on SPARQL expressions is the longest, covering 20 pages. And
> most of the functions are not defined in those 20 pages, but are only
> defined by reference to the XPath spec.


Yes, in fact the number of printed pages is not a good quantification of
the complexity of the language. If you take a look at those pages you can
see that most of them are examples.


> In O’Reilly’s book “Learning SPARQL”, authored by my colleague Bob
> DuCharme (which by the way I highly recommend to you),


Thanks, I agree that it is a nice book and I recommend it in my courses. I
have even a set of slides (in Spanish) based on the book that you may find
interesting [2].
I really don't know what you wanted to say with that remark, but I want to
repeat that I have no problem with SPARQL at all...I really think SPARQL is
a very good query language and can be used for a lot of nice validations.
You can even see my presentation at the validation workshop where I was
using SPARQL for complex statistical validations [3].

So the problem is not SPARQL, the problem is if we want to have a high
level language on top of SPARQL which can have other implementations apart
from SPARQL or if we want to offer a solution that only works in SPARQL.

the language feature chapters are 130 pages, and the expression language
> covers 50.
>
For comparison, the full XPath Functions and Operators spec is 152 printed
> pages.
>
> I really think that the expressions in the FILTERs are not the most
difficult part of SPARQL. I have been teaching SPARQL a lot of years in
several Universities and companies and for people with very different
backgrounds, and the main problems with SPARQL are not the SPARQL
expressions.

Best regards, Jose Labra

[1] http://www.w3.org/TR/sparql11-query/#expressions
[2] http://www.slideshare.net/jelabra/23-sparql
[3] PDF:
http://www.w3.org/2001/sw/wiki/images/d/d4/ValidatingStatisticalIndexData.pdf

Slides:
http://www.slideshare.net/jelabra/validating-statistical-index-data-using-sparql-qeries

>
> > Anyway, I had proposed it as one of two possible solutions to handle
> complex constraints. The other possibility is just to use the extensibility
> mechanism which would allow any SPARQL query.
> >
> > I now believe you are proposing designing a new language that, like
> SPARQL, would operate on RDF graphs to match graph patterns and bind
> variables and, like SPARQL, would include functions and operators (e.g.,
> addition) borrowing definitions of some of these from XQuery/XPath.
> >
> > 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]
> >
> > Best regards, Jose Labra
> >
> > [1] Conclusions of RDF Validation Workshop.
> http://www.w3.org/2012/12/rdf-val/report
> >
> > On Mar 1, 2015, at 11:41 PM, Jose Emilio Labra Gayo <jelabra@gmail.com>
> wrote:
> >
> >> On Mon, Mar 2, 2015 at 4:01 AM, Dean Allemang <
> dallemang@workingontologist.com> wrote:
> >> 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.
> >>
> >> Yes, that is more or less what I was proposing.
> >>
> >> My proposal was to have a construct in the language to bind variables
> to the subjects/objects that are matched and another construct that allows
> simple expressions using those variables.
> >>
> >> But my proposal was to limit those expressions to use the same
> expressions that can be used in the "FILTER" expression of SPARQL queries
> instead of any kind of SPARQL query, that's what I call "a controlled way"
> >>
> >> Best regards, Jose Labra
> >>
> >>
> >>
> >>
> >>
> >> 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
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> -- Jose Labra
> >>
> >
> >
> >
> > --
> > -- Jose Labra
> >
>
>


-- 
-- Jose Labra