Re: What we voted on at the f2f

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

Agreed. It sure would be nice to have some notion of what direction is
being taken, instead of an attempt to keep all options open. However, one
problem is that different working group members have different notions of
what direction should be taken. Another problem is that there is
misunderstanding of some aspects of some of the proposals. A third problem
is that it is hard to determine what is the best way to go without having
worked-out proposals for all the major options.

My view is that the entirety of SHACL needs firm foundations. That is why I
am against a separate definition of a portion of SHACL before there is a
definition of the whole of SHACL. (Well, actually, stuff that is ancillary,
such as nice error messages, probably doesn't need to be done at the same
time.) That is also why I am against including constructs in SHACL whose
foundations are problematic.

peter


On 03/26/2015 08:42 AM, Karen Coyle 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: 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
>>>> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVFC1bAAoJECjN6+QThfjzRIsH/1ERAwAE3Wz7qfuHq/Q7oy7L
QMex/lZExEeZ6KQdmT2we4Xg+AaAn8uFACqQhJEiTleNKn6FYA8kB9WPuJgG1x+7
STbH/kn7ypIqDWOnDOwFw3TepC7SFg/bJO5shJAbKWekJWKQSePMECwmgNvQQwec
zpUYt++NBBIOlCwaudeDoU6qdYrKo1ZgDad+K5IVtudSTjDsJIlljesUgXzapBcn
smDj2gtzYinhL+gtMbpwKeWsa9oJRoUf7SnIQpcOLVaYe7smLrjAQu5lkYQ3m2GU
FxS/t3eXm1ybIg6fEr171B4MZ9yh8R2wZmj2RqA3wJ2xjv/P0fVeY3xyw/NCQos=
=4Ubd
-----END PGP SIGNATURE-----

Received on Thursday, 26 March 2015 16:02:06 UTC