Re: What we voted on at the f2f

Karen,

There are certainly contentions that are blocking progress, but I canıt
help but think that this ³choice² is obfuscating the real underlying
issues and agendas.

It is perfectly possible to have:

- SHACL Semantics defined using SPARQL with (at least a subset of) the
specification implemented by an engine that doesnıt use SPARQL internally.
We even have a proof of this with the implementation built by Holger.
Whether there is any advantage in creating such implementations given
broad availability of SPARQL libraries is a different question and
answering it should be left to the implementers.

- Have some things in SHACL that are over and above of what SPARQL alone
can do, especially if these are small things. SHACL engines can add some
functionality on top of SPARQL functionality.

This approach also increases chances of having a significant number of
SHACL implementations, since most RDF technology vendors already support
SPARQL and, as a result, will find it easy to add support for SHACL.

We seem to be able to have the best of both worlds, satisfy everyone and
meet all the collected requirements. With this, I am struggling to
understand what is the real issue. May be it is, as Peter says, about
misunderstanding of some aspects of some of the proposals.

Irene


On 3/26/15, 11:42 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

>Peter, yes, I see this as another possible view. SHACL could be a
>language built on SPARQL, and in that case the specification would be
>"limited" to what constructs can be implemented in SPARQL and would be
>explicit about the dependency on SPARQL. I'm not against that, but what
>we have is neither SHACL built on SPARQL nor SPARQL-less SHACL, and the
>spec as written (and the discussions on the list) is neither one nor the
>other, but is fence-sitting.
>
>I'd like us to get off the fence, because I see that as the only way to
>move forward.
>
>kc
>
>On 3/26/15 7:47 AM, Peter F. Patel-Schneider wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I guess you mean that the undesirable goal is to have SHACL based on
>>SPARQL,
>> no matter whether this is reasonable or not. I certainly never have
>>thought
>> this way.
>>
>> As far as I am concerned the rationale for basing the meaning of SHACL
>>on
>> SPARQL is that
>> - - SPARQL is a standard
>> - - a lot of SPARQL has a well-defined declarative specification
>> - - SPARQL is suitable for the task
>> - - SPARQL has high-quality implementations which can be leveraged in an
>> implementation of SHACL
>>
>> Yes, my basing of SHACL on SPARQL does affect my thinking on what
>>constructs
>> should be in SHACL, but this is only one of a number of metrics that I
>>use
>> to determine what I think should be in SPARQL.
>>
>> peter
>>
>>
>> On 03/26/2015 07:32 AM, Karen Coyle wrote:
>>>
>>>
>>> On 3/24/15 10:18 AM, Irene Polikoff wrote:
>>>
>>>>
>>>> However, of course, once one defines the meaning of SHACL vocabulary
>>>> using SPARQL, they are half way (not all the way though) to the
>>>> implementation because SPARQL is executable. Thus, the view that SHACL
>>>> specification describes SPARQL-based implementation does have some
>>>> grounds. It is not a goal in itself, but a by-product of using SPARQL
>>>> to define the meaning.
>>>
>>> I'm fine with "however" as long as it remains a by-product, but it does
>>> at times seem to be treated as an actual goal. That is, I believe, the
>>> crux of the issue.
>>>
>>> kc
>>>
>>>>
>>>> Irene
>>>>
>>>> On 3/24/15, 1:04 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>>>>
>>>>> We clearly have different interpretations of the meaning of our vote
>>>>> at the face-to-face, which was:
>>>>>
>>>>> RESOLUTION: Define semantics using SPARQL as much as possible
>>>>>
>>>>> My view may be naive, but I took this to mean that the specification
>>>>>   would use SPARQL as the "abstract language" to define the meaning
>>>>> of the SHACL vocabulary. The minutes of the f2f show that the vote
>>>>> was taken in the context of a discussion of the "normative
>>>>> expression" for SHACL, and a "formalism." Others suggested included
>>>>> the use of Z as a formalism, but that didn't get much traction.
>>>>>
>>>>> There is another view, which is that the SHACL specification
>>>>> describes a SPARQL implementation, although other implementations
>>>>> are not excluded. This view treats the specification as a description
>>>>> of the SPARQL implementation, referring to it as a "built-in"
>>>>> language for SHACL. In this view, there is no "abstract language"
>>>>> formally defining SHACL.
>>>>>
>>>>> I see a rather large gap between using SPARQL as a formalism in the
>>>>> specification, and assuming that the SHACL standard is a SPARQL
>>>>> implementation. In fact, I don't think that we made a decision as to
>>>>> the implementation of SHACL or to any stated relationship between
>>>>> SHACL as a specification and any particular implementations of
>>>>> SHACL.
>>>>>
>>>>> However, as I said, my view may be naive, but I wonder if we can't
>>>>> clarify at least what we voted on at the f2f, since we seem to be
>>>>> intoning that vote in our discussion here with at least two different
>>>>> meanings.
>>>>>
>>>>> kc -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m:
>>>>> 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQEcBAEBAgAGBQJVFBwMAAoJECjN6+QThfjz33EIAJK5fRIRWsShenTd2qsz7dZy
>> v+gCU5jVSaMHfcICQy6FGUmgmVyJsEX8+Oo0XO0p7qvniSpuSAK8WKT8AKrx+Yzu
>> Z6k2b9bamJ+3BJCFXipb2Mop/1gPqRJ/96CgKp+D2GHm9WjgUuRHRKriOB3kQcZz
>> 3yp6px8cCwZFaA/zJAyyn8O+Ahw7tEn8SMVvrKeJYWci9DZKlOhMJwVO7Jv4g565
>> qvqyoxN7eeAe+IAyShhffPBRJr3cg/21oUpoSKu4AJNfamPDB5LJAAz/EF9IqdW6
>> aAVoCQPooooc64k/1XMkwVq9Y6NWDtucxKXxvVk1BpUYleCspnqNcs27oUnkmfg=
>> =nL+0
>> -----END PGP SIGNATURE-----
>>
>
>-- 
>Karen Coyle
>kcoyle@kcoyle.net http://kcoyle.net
>m: 1-510-435-8234
>skype: kcoylenet/+1-510-984-3600
>

Received on Thursday, 26 March 2015 18:18:49 UTC