Re: Follow-up on Michel's comment

Hi Holger,
  I want a language that sits on its own, with a clearly defined syntax and
semantics, and for which there can be a number of implementations. Since
SPARQL is an obvious choice, it makes sense to have a document that
specifies how SHACL expressions can be evaluated using SPARQL.

 What I worry about is that some users will simply resort to the templating
mechanism instead of articulating the constraint using the language,
thereby neatly causing a crisis in interoperability. You seem to dismiss
this possibility, but I'd rather be proactive on the point, and emphasize
that the templating mechanism should be used where SHACL standardization
fails to support a use case. With your vast experience, it would also be
useful to include use cases so that users can see how the templating can
get them further.

I also worry that those who wish to implement SHACL will be forced to parse
and interpret the arbitrary SPARQL expressions in templates. Therefore,
it's important to recognize that the templates, just as much as functions,
is a "if you need to do this, here's the vocabulary for it", but there's no
mandate by us that you have to interpret this. Some will, and others won't.
Thus, I'm ok with having clearly delineated profiles to handle these cases.

hope that clears up what i meant,

m.



Michel Dumontier, PhD
Associate Professor of Medicine (Biomedical Informatics)
Stanford University
http://dumontierlab.com

On Thu, Mar 19, 2015 at 5:07 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

>  Hi Michel,
>
> there was not enough time in the call, but I'd like to follow up on your
> comment that is recorded [1] as
>
> "I find it distracting to find SPARQL references in the main document.
> Separate document is best. I worry about templating mechanism as people
> will express constraints using templates vs. SHACL itself."
>
> It seems like you are basically saying you don't want SPARQL in the
> standard at all. Just moving it into another document will not make a
> difference. The current spec is clear enough about the possibility to use
> SHACL without SPARQL, and these will also be the first examples that
> everyone will see. The majority of users will not be exposed to SHACL via
> our spec first, but they'll see examples on the web, in Primers, tutorials
> and may be guided by editing tools. Finally, why should the SPARQL people
> be punished because some implementers want to only support a sub-set of the
> language. It would be like claiming that OWL = OWL Lite and pushing OWL
> Full into some dark naughty corner. Yes this has happened before, yet the
> OWL spec first includes all of OWL [2] and introduces profiles later. That
> is the way to go IMHO.
>
> Having said this, I cannot imagine that anyone would prefer to "declare"
> their properties in cryptic SPARQL instead of using sh:property, so I may
> have misunderstood your point.
>
> Thanks
> Holger
>
> [1] http://www.w3.org/2015/03/19-shapes-irc
> [2] http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/
>