W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

Re: Follow-up on Michel's comment

From: Michel Dumontier <michel.dumontier@stanford.edu>
Date: Thu, 19 Mar 2015 18:49:59 -0700
Message-ID: <CALcEXf7tJYyyds11ZtMb6oNRBY5CwnE51YNZWy5_hmsVPHUMeQ@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
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.

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>
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
>
>
>
Received on Friday, 20 March 2015 01:50:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:18 UTC