Re: SHACL specification document

On Sat, Mar 14, 2015 at 8:10 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

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

I also agree with that set of documents, and I also think that the best way
to proceed if with 2 & 3 written interatively so we can identify the main
features of the language.

Following Eric's language proposal:

http://w3c.github.io/data-shapes/semantics

I have started to define the axiomatic semantics of that language here:

http://w3c.github.io/data-shapes/semantics/Axiomatic

I created a "glue" section where I map the constructs in SHACL language to
the simplified abstact syntax:

http://w3c.github.io/data-shapes/semantics/Axiomatic#SimplifiedAbstractSyntax

and then, the document defines the axiomatic semantics of those constructs.

Notice that further extensions to the language could be done using the same
axiomatic semantics. For example, Closed shapes, negations, etc. could also
be defined. I moved those constructs out of the document for simplicity.

I have even a draft of constructs to define the extensibility mechanism and
even the macros facility, but I think it is better to start and agree on a
simple core language and add those constructs at due time.

I think that this document can be complemented with another document that
does the same using SPARQL.

And of course, it would be great if there are other formalization proposals
of the same language so the WG could later decide which formalization to
choose.

Best regards, Jose Labra

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


-- 
-- Jose Labra