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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

iQEcBAEBAgAGBQJVAxy+AAoJECjN6+QThfjzxu8H/13JWMLLzWB2MPMSJoYqZys3
LKQK6ndW7tp7vzpZKIsNDur37gVjTku/RDSV0y6AoCkeX7QEmWc3jYMzDmXAFU4O
NDs+EGSPv/grjyJolaznUgrM+xPZWFROZ+qD9kq2dAJrDd1SuyclAndUKTnhtQVc
7OgKAyCT8ZwG1us2iGvEZnwegOmO0m+ohoWjVhrhwBFrYtptmBRlEbF7Lm5V2SGd
AkoX/c/Ur/BmLYhop1KqlEfyHz2RCLxeGhtjtJ1CcqWwpdNGJtDYAV1ckeMlWR30
zsX4COzth/YPP58sV6ajnBei2gG8bBhTTdShDJvXFveU8S2az/9L7x2cLlSTv5w=
=srto
-----END PGP SIGNATURE-----

Received on Friday, 13 March 2015 17:22:36 UTC