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> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>> 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
> 
> iQEcBAEBAgAGBQJVAz8qAAoJECjN6+QThfjzaNAIAK5KFowQ8CwOabl8PwOsy8Rh
> xo83aMtupz1RvEYe+cP+M88CQDXttxdjPlFWHAXC+xQ4V/5ozss1LXmvtXwXt084
> 1gK0WG7I5jY5gEFillgvPgleVdeisR/q5Pc+CtRenTN6Kvlx7Z7rDHpT9PwNTq7t
> MgxecmU8vmx9Lwze6eylxSXHBb3qpc2ix1YxjfoQdqwxDJp8+3jVsm/FE37TnXkt
> ftNcEijAuX9Tfovhk7UqcG6zLtRqm31nfl4i+RdP5GAL0Gz8Gg+SSn69WkWwbDCQ
> 1Apwhn3F4O7zn29d+Or7J30Lq7jVMeqK5UIH14wl/1qVikEHiWpGUcFJ/EWprXk=
> =UerA
> -----END PGP SIGNATURE-----
>