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

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:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> 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
>>
>> iQEcBAEBAgAGBQJVAf12AAoJECjN6+QThfjzmIQIAJmZd8Z3mxE3klutnEpTehoC
>> W07T3dip5/n8JprBK5Lw1qpe8p8SyUyDQ1eVoelKXVnIHq7DWtbc1GFm7u2Rq/sJ
>> fw8WFeblQw6nSa4CnV9cxNP5bgItA1A6msj2ZBNx6vh4ZYnYRnPBDqWswYfO4zOY
>> sWwYdbrFlSQDct7dz1LPksybWQ4ghceLIUphNJ7lldYz73WsLqzUICOv9f0zn8kX
>> ZqJaVt1v94rev2exllmzvefzTm6sVB18sO8zYKE9q1NMdVmf8Y+9eD2IdYqu9X7q
>> 8y9KDMJR+4kGZ21EA0m6XzttZCmr54JfI51qNTQdipo8zTNx264cVOy/eb4bJBg=
>> =3veP
>> -----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 16:20:27 UTC