Re: SHACL: A language for multiple platforms

> Our answer to the Linked Data vision of completely interoperable models
is the Core Vocabulary. This will be the common ground that is supposed to
work everywhere. Users venturing into extensions need to be aware that they
are outside of convergence, and SHACL engines need to be built to fail
gracefully on unsupported features.

+1 to this. And +1 to the left side of your diagram.

On Fri, Jun 19, 2015 at 4:22 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

>  On 6/20/15 6:35 AM, Dimitris Kontokostas wrote:
>
> From my point of view a W3C spec should strive for convergence and not
> diversity.
>
>
> As soon as we voted in favor of SPARQL it was clear that not every SHACL
> file will work on every platform. Most SPARQL processors have their own
> extension functions (e.g. afn:localname, GeoSPARQL or even magic
> properties), and people do use them. The situation has become even more
> hopeless after the vote on allowing other languages beside SPARQL. Instead
> of seeing this diversity as a problem, I think we should embrace it as a
> reality and an opportunity. SHACL should allow people to get their work
> done, and much of this work will be in controlled environments such as
> enterprise applications.
>
> Our answer to the Linked Data vision of completely interoperable models is
> the Core Vocabulary. This will be the common ground that is supposed to
> work everywhere. Users venturing into extensions need to be aware that they
> are outside of convergence, and SHACL engines need to be built to fail
> gracefully on unsupported features.
>
>  We already have core + sparql. Now we want to break sparql into two
> modes and maybe javascript in another x modes in the future.
>
>
> I don't want to break SPARQL into two modes at all. My preferred outcome
> would be to rely on
>
> http://www.w3.org/2014/data-shapes/track/issues/71
>
> only. Any other access to SPARQL endpoints should be a temporary solution
> only. Vendors with native SHACL support will have a business advantage, so
> we hopefully see adoption of such a protocol soon.
>
>  I will certainly not block going into this direction but will not
> endorse it either.
>
>   These are entirely different setups, for different user groups. This is
>> not a one-size-fits-all discussion. If the SPARQL endpoint people don't
>> need access to ?shapesGraph, SHACL functions, recursion and blank nodes
>> then fine for me, but they should not block the dataset people from
>> covering their use cases.
>>
>
>  Besides ?shapesGraph I never mentioned blank nodes or shacl functions
> (which I am close to implementing). I already said I don't support
> recursion it but it's a big way from not supporting to blocking.
>
>
> This sounds good. I mentioned SHACL functions because SPARQL queries
> wouldn't be able to use them against SPARQL endpoints, unless you go
> through something like the protocol above.
>
> 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.
>
> So what are your thoughts on ISSUE-71? Would this help with your dbpedia
> use cases?
>
> Regards,
> Holger
>
>


-- 
-Tom Johnson