Re: SHACL: A language for multiple platforms

On 6/23/2015 16:00, Dimitris Kontokostas wrote:
>
>
>
>     BTW I noticed there is another complication if we dropped
>     ?shapesGraph: template arguments can be rdf:Lists that are stored
>     in the shapes graph. In order to walk these lists, ?shapesGraph
>     access is needed. To get rid of this we would need to come up with
>     a fairly sophisticated text insertion mechanism that generates
>     various alternative SPARQL serializations for different use cases.
>     And even then I don't see how we could implement order-preserving
>     scenarios such as the tail recursion implemented by the
>     sh:walkShapesList and lists of bnode shapes. An alternative again
>     would be to disallow rdf:List arguments outside of the core, but I
>     know from experience that SPIN users asked about multi-valued
>     template arguments.
>
>
> I am not sure I understand the problem with list/non list arguments, 
> maybe you can send me an offline example.

Templates and functions may take rdf:List arguments, but these are just 
references to the start node. In order to walk these lists, the queries 
need to walk rdf:rest/rdf:first triples, which are stored in the 
?shapesGraph, i.e. need to be surrounded by GRAPH ?shapesGraph { ... }. 
An example is the default implementation of sh:allowedValues.

> I am also in favor of this feature and RDFUnit supports multiple 
> arguments but with a kind of more verbose syntax e.g.
>
> definition: 
> https://github.com/AKSW/RDFUnit/blob/master/configuration/patterns.ttl#L31-L52
> binding: 
> https://github.com/AKSW/RDFUnit/blob/master/data/tests/Manual/dbpedia.org/ontology/dbo.tests.Manual.ttl#L26-L40
>
> Of course functions that use sh:hasShape will have to be implemented 
> in a different way, for sh:walkShapesList my approach would be to 
> preserve the order but move all the AND/OR/XOR/NOT/... calculation in 
> the shacl engine

I would be curious how this would work in detail, because most SPARQL 
operations don't have an ordering - even && and || are not ordered in 
the sense that the right operand isn't executed if the left one has a 
certain value. That's also why I propose that the proponents of the code 
generation approach write this down as a technical spec. It may sound 
easier in theory than it is in practice, yet we would get a clearer 
direction for people who really only have vanilla SPARQL endpoints as 
their interface.

>
>     So what are your thoughts on ISSUE-71? Would this help with your
>     dbpedia use cases?
>
>
> My suggested resolution is in this direction, we allow all your design 
> but disallow some parts outside of core.

If we used ?shapesGraph in the core then it would also be valid to have 
implementations that rely on ?shapesGraph in the SPARQL bodies of the 
core language. Then, how would we prevent others from using the same 
feature outside of the core? Another consequence would be to also drop 
sh:hasShape support outside of the core (and thus recursion), and it 
remains unclear what to do about rdf:Lists.

I believe instead of generally dropping these features we should rather 
define a "SPARQL endpoint-safe subset" of SHACL similar to OWL Lite. In 
that subset we would:
- reject queries that use the variable ?shapesGraph
- reject queries that use SHACL functions
- reject recursive shapes
- report errors if validation returns blank nodes
All this is quite easy to specify and detect, but would keep the current 
flexible design for those who are not limited to SPARQL endpoints. We 
cannot wait five years for a SHACL 2.0. Meanwhile, vendors will create 
their own inofficial variations that offer more features than the standard.

My hope is that this subset will become less and less relevant once 
ISSUE-71 is implemented, but it may be useful for the first couple of 
years of the initial adoption of SHACL.

Thanks,
Holger


> This is a decision we can change with no cost later in the process or 
> the next shacl version
> ISSUE-71 would definitely help but members from sparql engines would 
> be better fit to comment this
>
> best,
> Dimitris
>
>
>     Regards,
>     Holger
>
>
>
>
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia 
> Association
> Projects: http://dbpedia.org, http://http://aligned-project.eu, 
> http://rdfunit.aksw.org
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: http://aksw.org
>