Re: SHACL: A language for multiple platforms

> 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. I am also in favor of this feature and
RDFUnit supports multiple arguments but with a kind of more verbose syntax


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

> 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.
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


> Regards,
> Holger

Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects:, http://,
Research Group:

Received on Tuesday, 23 June 2015 06:01:35 UTC