Re: STRAWPOLL on Approach for SHACL

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>> 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

Received on Thursday, 2 April 2015 05:44:08 UTC