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

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