Re: SHACL specification document

This set of three documents makes sense to me. I wouldn't object, 
however, if documents 2 & 3 are written iteratively, since document 2 
will probably surface more interaction between the language and the use 
cases/requirements.

kc

On 3/14/15 10:00 AM, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I think that these points are irrelevant when considering a specification
> document, whose purpose is to formally define SHACL.  Perhaps, however, some
> people are thinking that the specification document is going to be read by
> people who just want to know how to write simple SHACL constraints.  I don't
> view this as the intended audience of the specification document at all.
>
> Instead I think that there are three documents (or document sections) that
> need to be written, but maybe not all by the working group.
> 1/ A Primer that introduces SHACL and is intended to be read by anyone who
> is interested in SHACL.  The Primer would likely suffice for users who will
> only be writing very simple SHACL.
> 2/ A Guide that sets out all the SHACL constructs and is intended to be read
> by anyone who wants to write SHACL beyond the simplest.  The Guide should
> probably set out the simpler constructs first and only later delve into the
> more complex constructs.
> 3/ A Specification that serves as the formal definition of SHACL.  The
> Specification should be organized so that the fundamental constructs come
> first.  If SHACL is based on SPARQL then SPARQL would show up at the
> beginning of this document and, indeed, probably everywhere else.  The
> Specification is intended as a reference for implementations of SHACL and to
> determine what SHACL constructs mean if the other documents are insufficient.
>
> My view is that it is the Specification that needs to be written first, for
> two reasons.  First, a formal specification nails down what the various
> constructs of SHACL mean in isolation.  Second, a formal specification is
> needed to show that the entirety of SHACL actually has a viable basis.
>
> peter
>
>
> On 03/13/2015 06:25 PM, Arnaud Le Hors wrote:
>> I actually think Karen brings up a good point. For example, I think the
>> Graph Store Protocol has failed to get more adoption because of the way
>> it was defined using SPARQL. The fact that SPARQL is in the official name
>> only made it worse obviously but I for one had assumed it was related to
>> SPARQL and a quick look at the spec led me to believe that was the case,
>> even though it wasn't. It's only later when I was told that it wasn't and
>> I had a second look that I really understood that.
>>
>> So, I think Karen is right in that this is likely the impression that
>> people will get if we have SPARQL sprinkled all over the spec and
>> changing that perception  will be an uphill battle moving forward.
>>
>> Saying that if nobody implements it without SPARQL it's because they see
>> no value in doing so is therefore missing the fact that people may not
>> even realize there could be value in doing so and not give it proper
>> consideration. A kind of self-fulfilling prophecy.
>>
>> Besides, I heard Holger say that he wants to make something that will be
>> appealing to non RDF developers. If that's the case, it seems misled to
>> justify using SPARQL on the basis that people are familiar with it.
>> Clearly these aren't the same people. So, who is our target audience? We
>> have an open issue on this. -- Arnaud  Le Hors - Senior Technical Staff
>> Member, Open Web Technologies - IBM Software Group
>>
>>
>>
>>
>> From:        Irene Polikoff <irene@topquadrant.com> To:        "Peter F.
>> Patel-Schneider" <pfpschneider@gmail.com> Cc:        "kcoyle@kcoyle.net"
>> <kcoyle@kcoyle.net>, "public-data-shapes-wg@w3.org"
>> <public-data-shapes-wg@w3.org> Date:        03/13/2015 03:47 PM Subject:
>> Re: How would option b) on the last straw poll of 12 March work?
>> ------------------------------------------------------------------------------
>>
>>
>>
>>
>> How is this a bad thing? If there is not sufficient benefit to
>> implementations that are not based on SPARQL implementations for them to
>> be developed, then there can't be much loss, can there?
>>
>> Exactly. If there is interest and value, I don't believe that having
>> semantics precisely articulated using SPARQL would stop people from doing
>> non SPARQL implementations.
>>
>> If there is not enough interest or value, then there is no loss.
>>
>> In fact, I believe using SPARQL to express semantics would, if anything,
>> facilitate and enable different implementations. There are considerably
>> more people who would be able to understand the meaning of the language
>> then if the spec was done some obscure formalism very few people know or
>> be motivated to learn.
>>
>> Irene
>>
>> On Mar 13, 2015, at 3:48 PM, Peter F. Patel-Schneider
>> <_pfpschneider@gmail.com_ <mailto:pfpschneider@gmail.com>> wrote:
>>
>> On 03/13/2015 12:21 PM, Karen Coyle wrote: Peter, a non-normative primer
>> could well handle the comprehension issue, but I'm afraid that the
>> "intertwining" -- assuming we are not creating SHACL as an extension of
>> SPARQL -- would still require some work. Although, as you say,
>>
>> "A SPARQL-based formal specification for SHACL does not mandate a
>> particular implementation any more than a Z-based spec or a model-theory
>> based spec or an axiomatization does",
>>
>> in reality (e.g. the part of it that most humans occupy) it does because
>> those latter are not commonly used implementation or programming
>> languages (AFAIK).
>>
>>
>> The problem with SPARQL as the focus for the spec is that it IS an
>> implementation, not an abstraction.
>>
>> I guess that we will have to disagree on this.
>>
>> That it can express the formal semantics of SHACL does not make it a
>> modeling language.
>>
>> This can also be said of axiomatizations. Would you have the same
>> problem with a SHACL specification in terms of an axiomatization?
>>
>> My concern is that SHACL will be so closely associated with SPARQL that
>> other implementations will not be developed because it will read like an
>> extension of SPARQL.
>>
>> How is this a bad thing? If there is not sufficient benefit to
>> implementations that are not based on SPARQL implementations for them to
>> be developed, then there can't be much loss, can there?
>>
>> If we leave the spec as it is, it seems to me that we should go ahead and
>> follow your suggestion of building SHACL on SPARQL explicitly, without
>> the pretense of it being open for other implementations.
>>
>> I don't think that I have ever said my proposal precluded other kinds of
>> implementation A while ago I even put in a comment that all that counts
>> is the results, not how they are obtained.
>>
>> That at least would be clear, and if the remainder of the world doesn't
>> buy that, at least they've got a clear target to disagree with.
>>
>> Fine by me.
>>
>> kc
>>
>> peter
>>
>> On 3/13/15 10:22 AM, Peter F. Patel-Schneider wrote: Would having a good,
>> non-normative primer handle both your comprehension and intertwining
>> issues?  If so, then the specification document for SHACL is freed from
>> any concerns about providing an introduction to SHACL and can concentrate
>> on presenting the formal specification for SHACL.
>>
>>
>>
>> A few other points:
>>
>> 1/ A SPARQL-based formal specification for SHACL does not mandate a
>> particular implementation any more than a Z-based spec or a model-theory
>> based spec or an axiomatization does.  Having SPARQL syntax show up in
>> parts of SHACL does, of course, intertwine SHACL and SPARQL, but that's
>> still not implementation.  Having SHACL formally based on SPARQL does
>> permit an easy route to efficient implementations, but that's yet another
>> feature that is different from mandating a particular implementation.
>>
>> 2/ Having a particular formal specification for SHACL does mean that that
>> is *the* formal specification of SHACL.  Examples showing how to think of
>> SHACL in other ways would be only informative.  This is independent of
>> whether the formal specification is based on SPARQL or Z or sets or
>> whatever.
>>
>> 3/ Having the formal basis of SHACL be SPARQL does not prevent the
>> development of application profiles that use very different
>> implementation techniques than would be required for an implementation of
>> all of SHACL. OWL 2 DL is based on a particular model theory and
>> implementation of all of OWL 2 DL requires, in effect, a sophisticated
>> theorem prover.  However, there are OWL 2 profiles that can be
>> implemented using very different techniques but that are nonetheless
>> based on the same exact same model theory that underlies OWL 2 DL.  In
>> fact, the profiles are specified syntactically, and the same technique
>> can be used in SHACL.  It appears to me that DCMI application profiles
>> can be built no matter how specification for SPARQL looks.
>>
>> In the end, if there is going to be a formal specification for SHACL,
>> then there has to be a formal specification for SHACL.  This formal
>> specification can be done in many ways, some better and some worse.  The
>> formal specification does not have to be mentioned in introductory
>> material and the techniques that it uses do not have to be used in
>> implementations.  (This is true to the point that if SHACL is specified
>> via a translation to SPARQL then even implementations of SHACL that just
>> are translations to SPARQL do not have to use the translation that is
>> provided in the formal specification of SHACL.)
>>
>> peter
>>
>>
>>
>>
>> On 03/13/2015 09:19 AM, Karen Coyle wrote: I'll tell you what I had in
>> mind, and why I asked the question I did of Arnaud before the call:
>>
>> I would like to see, either in a separate document or as the opening
>> section of a single document, a spec that describes the language of SHACL
>> without leaning on any particular implementation. This would be
>> introductory, and may not be sufficient for development, but would be
>> explanatory for many. Jose's draft is close to what I mean, but it even
>> could be less formal if the formal definitions are provided elsewhere.
>> Then I would like to see a spec that has an implementation of each
>> function using sparql. I don't know if sparql is the best or sufficient -
>> I leave that to others. There are folks on the list who have indicated
>> that they would use other languages (I believe javascript was
>> mentioned?). A few examples should be given showing how other languages
>> could be used, possibly within the document or in an appendix.
>>
>> There are two reasons for my preference: the first is comprehension,
>> which is that an overview of the language will be needed by some in order
>> to comprehend what the language is intended to do, before going into all
>> of the sparql examples, which are not useful to anyone not deeply
>> familiar with sparql; the second reason is that I would like there to be
>> an overview that is not so directly intertwined with sparql. The current
>> spec reads like a sparql implementation, without giving more than lip
>> service to other possibilities.
>>
>> It does appear that best way to provide a separation between SHACL and
>> SPARQL is to have separate specs. I think it could be done in a single
>> document, but the document would have to have editors that were willing
>> to make that separation.
>>
>> The other option, which Peter has proposed, is that SHACL be developed
>> explicitly as an implementation of SPARQL. That changes the group's
>> direction a bit, IMO, because it probably would not fulfill the aspects
>> of the group's mission that I see as being a support of what DCMI called
>> "application profiles." Those go beyond validation of instance data to
>> definition of data models and provision of documentation. We may need to
>> separate the validation and the AP functions. I think that could work. In
>> DCMI we are looking to modify the DSP [1] to fill in the modeling and
>> documentation aspects as a response to the direction it appears that this
>> group is taking.
>>
>> kc [1] _http://dublincore.org/documents/dc-dsp/_
>>
>> On 3/12/15 3:00 PM, Holger Knublauch wrote: Furthermore, what did people
>> actually vote for:
>>
>> b.1) Only the higher-level language shall become standard and SPARQL
>> could be an add-on outside of the standard (e.g. shaclx:sparql)
>>
>> b.2) Both the higher-level language and SPARQL would become standard but
>> in separate deliverables, both normative.
>>
>> The wording "main specification" leaves both interpretations open. With
>> b.1 the obvious consequence will be that nobody will use SPARQL because
>> it will be regarded as vendor-specific extension.
>>
>> Thanks, Holger
>>
>>
>>
>>
>> On 3/13/15 6:56 AM, Peter F. Patel-Schneider wrote: There were a number
>> of WG members who voted for: b) The main specification shall include the
>> higher-level language constructs only and the rest shall be defined in
>> add-ons.
>>
>> Can any one describe how this option would work?  Would there be a single
>> way of defining the meaning of the entire language (main spec and
>> add-ons) or would there be several ways of the defining what constructs
>> mean?
>>
>>
>>
>> peter
>>
>>
>>
>>
>>
>>
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVBGktAAoJECjN6+QThfjz2SsH/29erOnwwP+JWvObR6bS85K0
> TL8KeM/jik84oRXIge5kj/86cJgGdqYYxD3BZNvUf5H2uJ3LbiV3hjPYgAKXJsKO
> A8ZHmzeJY1X9agVA6hqx0ih9N/Zvgop1L9stG0kClUGIqFnDPnHNRONKDVc3rzfi
> H/qQkYokH/voMQfiW+ePbnozQuLWHpPQKIr6b2ngURSa2Y24p6xbauNBdoBWPeck
> g4VHLDPhkkFS1/ADl4lAoASDIjHzcYImgnvBdow+NT0hQWFS9BiqRXPGungx7YAa
> eKrq1DfD5mklF4hk5I4ltwEp1CKaDfr06767YfPp98pBZO7gJMCseubRZrzVg3s=
> =5RRu
> -----END PGP SIGNATURE-----
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Saturday, 14 March 2015 19:10:56 UTC