W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: Shapes/ShEx or the worrying issue of yet another syntax and lack of validated vision.

From: Kendall Clark <kendall@clarkparsia.com>
Date: Fri, 18 Jul 2014 12:24:55 -0400
Message-ID: <CAHb4HxiwLRCGsDCidJ+hh=gTR0-VG1io5LAK+bpSdX=uv4j5Yw@mail.gmail.com>
To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Cc: Jose Emilio Labra Gayo <jelabra@gmail.com>, Jerven Bolleman <jerven.bolleman@isb-sib.ch>, "Dam, Jesse van" <jesse.vandam@wur.nl>, "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
On Fri, Jul 18, 2014 at 12:20 PM, Dimitris Kontokostas <
kontokostas@informatik.uni-leipzig.de> wrote:

>
>
>
> Instead of criticizing what ShEx can't do we should all try to see what
> ShEx should do.
>

Why? Standards bodies should be about standardizing existing systems. This
is one thing the W3C has consistently gotten wrong in the semantic web
space: too much speculative research done in the guise of standardization.


> I think we all agree that a compact human syntax (with equivalent RDF
> representation) that covers common validations cases and SPARQL extensions
> is something we all want.
>

SPIN, IBM Resource Shapes, and Stardog ICV already provide that. You can't
get any more compact human syntax than, say, Manchester OWL syntax for
constraints: see http://docs.stardog.com/icv for many *real* examples from
shipping code.


> I too don't like some parts of ShEx but I think it's a good initiative to
> bootstrap a standard.
>

That isn't how standardization works best.


> I already raised some issues in the mailing list and have a few more from
> my experience with RDFUnit - but will raise them later since the
> maintainers are now too busy replying.
>

Those are all valid, interesting points for ShEx, which is at this point an
interesting proof of concept or prototype of an idea. That work should be
carried out in an R&D context. W3C Working Groups are not R&D contexts.

Cheers,
Kendall Clark
Received on Friday, 18 July 2014 16:26:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC