Re: Follow-up on Michel's comment

On 3/20/2015 11:49, Michel Dumontier wrote:
> Hi Holger,
>   I might suggest that we look at what other WGs have produced. For 
> instance, the OWL WG produced a number of documents to lay out the 
> syntax, semantics, profiles, etc [1]. Similarly, the SPARQL 1.1 
> working produced a collection of documents [2] to address different 
> issues, and to ensure completeness for each. Given the breadth of 
> topics, it seems like a worthy idea for this WG to consider as well.

The SPARQL spec is basically a single large document that even includes 
the Grammar and Definition of SPARQL. As stated by Arthur, many people 
use this as a reference to look up details about SPARQL. It is 
convenient that they only need to look at a single place (with text 
search etc). For those users who will use both the high-level features 
and SPARQL, it will be unnecessarily complex to switch between two 
documents.

With OWL 2, the situation was more complex because OWL's language stack 
is much more complex than SHACL. Yet the main document (the Structural Spec)

     http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/

basically includes all overall features in a single place, and then the 
sub-sets are formally defined in a Profiles document

     http://www.w3.org/TR/2012/REC-owl2-profiles-20121211/

That's how I would organize the SHACL spec too, only that the SHACL core 
profile only needs a single sentence to explain, so there is no need to 
turn that into its own document.

Thanks,
Holger


>
> m.
>
> [1] http://www.w3.org/TR/owl2-overview/
> [2] http://www.w3.org/TR/sparql11-query/
>
>
>
> Michel Dumontier, PhD
> Associate Professor of Medicine (Biomedical Informatics)
> Stanford University
> http://dumontierlab.com
>
> On Thu, Mar 19, 2015 at 6:38 PM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     On 3/20/2015 10:37, Michel Dumontier wrote:
>
>         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.
>
>
>     Yes, this language is currently called SHACL Core Profile (or
>     SHACL Lite) and described in sections 2 - 6. It also has a SPARQL
>     specification in the later chapters of the document. The Core
>     Profile could have other formal definitions in separate
>     deliverables, yet the consensus was that SPARQL should be used
>     where possible.
>
>
>          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.
>
>
>     Yes of course, it should already be clear that people SHOULD use
>     the built-in templates whenever they can. If there are means to
>     make this recommendation even stronger, I'd be happy to hear about
>     that.
>
>
>         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.
>
>
>     Yes that describes the current plan.
>
>
>         Thus, I'm ok with having clearly delineated profiles to handle
>         these cases.
>         hope that clears up what i meant,
>
>
>     The reason why I picked on this question (and apologies for
>     drilling down on your statement), is that the WG struggles with
>     the decision on how many normative deliverables should be
>     produced. Can I interpret your statements above that you would not
>     object to a single document as long as it has clearly delineated
>     profiles?
>
>     Holger
>
>
>