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

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. That it can express 
the formal semantics of SHACL does not make it a modeling language. 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. 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. 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.

kc

On 3/13/15 10:22 AM, Peter F. Patel-Schneider wrote:
> -----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-----
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Friday, 13 March 2015 19:21:39 UTC