Re: Role of SPARQL

I'm also just catching up to this long discussion - but this seems like a
good place to jump in.

I am very strongly attracted to basing Shapes in some way on SPARQL, for
the following reasons:

1) SPARQL is already a successful standard, with many implementations and
broad uptake (well, by Semantic Web standards, anyway)
2) In my experience, software engineers who are not antagonistic to
Semantic Web standards take quickly to the idea of representing constraints
in SPARQL.  Business analysts, too, though I have fewer examples of that.
3) Extensibility of SPARQL has been practically established in the Jena
framework and in current SPIN implementations.  Standardization of this
extensibility would help SPARQL gain more coherence across implementations,
having benefits beyond the core Shapes use cases.
4) The (programming-language) semantics of a SPARQL expression have already
been settled, so we don't have to re-do this work.

These are all very good reasons to have SPARQL in the stack, so I guess I
am disagreeing with the suggestion from Arnaud to specify this without
reference to a technology; I think that referring to SPARQL in particular
buys us a lot.

Some of these benefits also hold for OWL, but since we would need to
re-interpret OWL as a closed-world language for a lot of our use cases,
this causes a bit of an overloading of OWL semantics.

I think there is probably a similar benefit list to be had from more
ShEX-like structures (readability is one that has been proposed, but that
is a pretty subjective matter; perhaps that can be made a bit more
objective)

It seems to me that we can take advantage of these values of having a
SPARQL-based shapes language by defining syntactic sugar over other
languages (more shape-like ones) by defining them in terms of their SPARQL
implementation (we've already seen some efforts in that direction).  The
closed-world meaning of OWL in SPARQL has already been worked out by the
Pellet ICV (which I think is why Kendall told me (referring to ICV and
SPIN) that "*they're precisely the same thing*" )

There are details about how to anchor thing when the type isn't specified
and whether shapes must always correspond to classes, but those seem like
the detailed work that the group will have to perform.  But the idea of
using SPARQL as the expression and execution layer of the standard (thereby
layering this standard on top of a previous, successful standard) seems
pretty clear to me.



Dean




On Sat, Nov 22, 2014 at 7:37 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

>  Whatever language syntax is decided, some interoperable mechanism needs
> to be found to perform the actual queries against a dataset. These queries
> can be quite complex graph patterns. SPARQL is an obvious choice here.
>
> Stardog ICV compiles to SPARQL. ShEx has a SPARQL mapping. Resource Shapes
> is a subset of ShEx. SPIN executes as SPARQL. RDFUnit does.
>
> So I am wondering whether anybody disagrees on this topic at all, and
> whether we can use this opportunity to narrow down the space of open issues.
>
> The resolution could be that we make it a requirement for any solution
> that it needs to be executable with SPARQL. This topic is separate from the
> surface syntax.
>
> I am just trying to be pragmatic.
>
> Thanks,
> Holger
>
>
>
> On 11/22/14, 3:23 AM, Arnaud Le Hors wrote:
>
> Is this something we can resolve without knowing which technology we are
> going to use though?
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - IBM
> Software Group
>
>
>
>
> From:        Holger Knublauch <holger@topquadrant.com>
> <holger@topquadrant.com>
> To:        public-data-shapes-wg@w3.org
> Date:        11/20/2014 03:22 PM
> Subject:        Role of SPARQL
> ------------------------------
>
>
>
> I think we should raise an issue to determine the role of SPARQL in this
> stack. One of the reasons why I believe this is an important direction
> is that it will impact ISSUE-1 (inferencing). For example, see the
> unresolved feature request brought to our attention by Axel:
>
> http://www.w3.org/2009/sparql/wiki/Feature:ParameterizedInference
>
> The interaction is that if SPARQL (in general) had a syntax to specify
> entailment regimes, and Shapes are based on SPARQL, then the topic of
> inferencing may become a non-issue from a Shapes perspective - it would
> be solved in the lower parts of the stack.
>
> From what I can guess by listening to previous discussions, many people
> here are in favor of defining Shapes with SPARQL semantics, at least
> with a mapping/compilation to SPARQL, so I believe this is a topic that
> we should formally discuss and resolve.
>
> Holger
>
>
>
>
>