Re: STRAWPOLL on Approach for SHACL

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

So you are against using SPARQL as the sole means for defining the meaning
of SHACL and against using SPARQL as the extension mechanism and for having
a richer high-level language.

I think that it is now time to present a proposal along these lines to be
evaluated by the working group.

peter


On 04/01/2015 10:43 PM, Jose Emilio Labra Gayo wrote:
> I think I have already described my point about SPARQL and SHACL in other
> threads.
> 
> - I have no problem to define a semantics of the SHACL high-level
> language in SPARQL when it is possible to do so. However, I also think
> there are other means to define the semantics that should not be
> discarded. Although I proposed an axiomatic semantics, I have already
> said that I would not oppose to other semantic formalisms. In fact,
> something like the model based semantics that you drafted in another
> email would be nice and I have started to work in that direction also.
> 
> - I am against tying SHACL to SPARQL in a way that SHACL can only be 
> implemented via a full SPARQL engine.
> 
> - I am in favour of defining a rich enough SHACL high-level language that
> can be used for most of the common RDF validation tasks.
> 
> I am against limiting the expressiveness of SHACL to the things that can
> only be expressed in SPARQL. I think SPARQL is a very nice query language
> but it was not designed for RDF validation and SPARQL is not a good
> language for that task.
> 
> I think this WG was chartered to create such a language and we are
> loosing a lot of time discussing how to implement the language without
> discussing what is the language. As a W3c WG we should define something
> useful and open enough to accommodate different implementations without
> imposing a specific implementation approach.
> 
> I am not opposed to include a language construct that can call an
> external processor to express more complex constraints. But that external
> processor can be SPARQL, Javascript, or whatever. SHACL implementations
> should not be forced to implement the SPARQL extension.
> 
> Best regards, Jose Labra
> 
> 
> Are you against using SPARQL as a specification formalism for the
> high-level language of SHACL even if there is no need to use a SPARQL
> implementation (or equivalent) to actually implement the high-level
> language of SHACL?
> 
> If so, what aspects or features of such a specification are you against?
> 
> peter
> 
> 
> On 03/26/2015 10:52 AM, Jose Emilio Labra Gayo wrote:
>> I was going to vote but reading the options, they are both options 
>> reasonable, what worries me is if there is some hidden implication
>> about the relationship between SHACL and SPARQL.
>> 
>> If option a) doesn't imply that the high-level language constructs
>> will be merged with the SPARQL definitions, I would not have a problem
>> if they are in the same document but in separate sections.
>> 
>> However, if voting option (a) implies that the high-level language
>> will be tied to SPARQL as it currently is, the my vote will be
>> against.
>> 
>> Best regards, Jose Labra
>> 
>> 
>> On Thu, Mar 26, 2015 at 2:36 AM, Arnaud Le Hors <lehors@us.ibm.com
>> <mailto:lehors@us.ibm.com> <mailto:lehors@us.ibm.com
>> <mailto:lehors@us.ibm.com>>> wrote:
>> 
>> There has been a lot (!) of discussion on the mailing list and I'd
>> like to get an update on where the WG stands with regard to the
>> different approaches being proposed. I know this doesn't capture all
>> the issues (obviously) and some will feel that this isn't the right
>> question but at least this is one point of contention that we need to
>> address so, please, bear with me.
>> 
>> Rather than doing this just on a teleconference I set up a wiki page
>> so that who can't attend the teleconference can still respond: 
>> https://www.w3.org/2014/data-shapes/wiki/Strawpoll_On_Approach
>> 
>> Thank you. -- Arnaud  Le Hors - Senior Technical Staff Member, Open
>> Web Technologies - IBM Software Group
>> 
>> 
>> 
>> 
>> -- -- Jose Labra
>> 
> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
> 
> iQEcBAEBAgAGBQJVGbUhAAoJECjN6+QThfjz4YcIAKPfBa9XucZ1sRmxghaHqlq1 
> 1M0umxM79QXRBjNL3qO1R2QZRGo3tgrrZf0cKTBJOXFSRaEyX5g7nZuy3gGkFHNz 
> jrjN393t9wNZ4ZVJLPTN+zsETECeSlwho6k2qGheX1DS/biwfeUg9ZSJx2d/Av+v 
> faT8yQN7dR4I3GDiSl4uL3VZfdkqqzq56mGlzTocPDfiLNMThBaJX6dn/WuWnzMF 
> XjPITr42kwFeow4Cq0DQ4OgqvoahRA0EtVmI+IoBEVcj/yJgxSzn9qc6UvwV7HPd 
> EQEe1dHN9eUwUlHdQWynn8PlO942qroeP4Nqa120Vo3Egowr8A94RcK0q3+l7Ig= =pLs4 
> -----END PGP SIGNATURE-----
> 
> 
> 
> 
> -- -- Jose Labra
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVHSW4AAoJECjN6+QThfjz6OEIAKvaTt4lLM60FI41TlOLn9ck
vRoJDSCvMjkAbDgCdMMuJFma3BI2adKGSi0TDvou7u59CQZlBGlYqfNK0i4ei3TQ
8whrhabsJjeC7+mHnaWXYgZMr76u7yImuvFVJ5yCjyaXn+gUo0xLXxeG9m63BAzq
BYGxBXz2fWKjfHxdfh5MYGlr0T43g2K6XfUKyVA5bcZNOsALh612qamhC7U18Z+o
oTJAX6+6g6O4WugWaw6/paJzi8HYz+HCusLu0fMJ1ri/4B6q0wbknwuqu4LUAXrS
WWHPD9F2kdy3+XfrVUK5sKTF31NIH6i/a3MhP44mP6VF2TyojdoeQD5x1Y9i2kc=
=z4BP
-----END PGP SIGNATURE-----

Received on Thursday, 2 April 2015 11:19:50 UTC