Re: Role of SPARQL

There are many possibilities for providing a definition of constraints that 
can be used to build interoperable implementations.

The definition could be a specification in Z.  It could be a specification 
using the RDF semantics.  It could be a specification using the OWL semantics. 
  It could be a specification employing an algebra on RDF graphs and datasets. 
  None of these utilize queries against a dataset.

None of the above are incompatible with also having a translation to SPARQL 
that provides a path to a complete implementation, but none of the above 
require SPARQL at all.  Even if there is a translation to SPARQL it may turn 
out that implementations end up not using the translation.

Translatability to SPARQL is probably a good thing, but making even this be a 
hard requirement is a bad idea in my opinion, especially this early in the 
process.

peter

PS: Are there any proposals that can be completely translated into SPARQL?  By 
this I mean that constraint checking can be performed by executing a set of 
SPARQL queries against the RDF graph or dataset with no post-processing.  This 
might be the case for SPIN constraints, but I'm not sure of that.


On 11/21/2014 12:37 PM, Holger Knublauch 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>
>> 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
>>
>>
>>
>

Received on Monday, 24 November 2014 16:56:52 UTC