Re: How would option b) on the last straw poll of 12 March work?

-----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-----

Received on Friday, 13 March 2015 19:49:28 UTC