- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 28 Mar 2017 21:08:46 -0400
- To: John Walker <john.walker@semaku.com>
- Cc: Gregg Kellogg <gregg@greggkellogg.net>, W3C Semantic Web IG <semantic-web@w3.org>, "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>, "public-shex@w3.org" <public-shex@w3.org>, "Solbrig, Harold R." <Solbrig.Harold@mayo.edu>
* John Walker <john.walker@semaku.com> [2017-03-28 08:53+0000] > Hi Gregg, > > Does there exist somewhere a (preferably objective) comparison of ShEx and SHACL? > Would be a useful resource for people trying to decide which to use/implement. > > Something along the lines of: > https://www.w3.org/2012/ldp/wiki/Linked_Data_Platform_(LDP)_vs_SPARQL_Graph_Store_HTTP_Protocol_(GSP) We don’t have this sort of resource today, as both specifications are just solidifying. An exhaustive comparison is definitely needed but here’s a start at it. Objectives: Both ShEx and SHACL began with the same objectives: * Defining and publishing topology and value constraints on nodes in an RDF graph - a "shape" * Formal verification of data with respect to a shape * Human readability ShEx emphasizes the human readability aspect using compact grammar, while SHACL focuses on RDF as the primary representational form. Both started with an expressivity similar to Resource Shapes. ShEx was extended to meet use cases that demanded repeated properties (e.g. a pizza topping that is cheesy and another that is meaty) we these are common in health care. SHACL's design is more similar OWL in its treatment of OR or qualified cardinality constraints. ShEx has a logical language for such connectives but the objective was to be a grammar for graphs, i.e. that property constraints be expressed the same for singleton properties as for distinct constraints on repeated general properties. (This grammar behavior comes from ShEx being a regular language over a "partition".) Expression: SHACL is defined in terms of an RDF vocabulary; ShEx defines an abstract syntax with three concrete representations: ShExC (compact syntax), ShExJ (JSON), ShExR (JSON-LD interpreation of ShExJ). The ShExC syntax is intended for human creation and consumption, while ShExJ is intended to be composed procedurally (e.g. the translation from other schema languages) or by click-y interfaces. Extensibility: The ShEx compact syntax and abstract syntax have provisions for callout to arbitrary functions. The test suite defines a single extension language <http://shexspec.github.io/extensions/Test/> which can fail a validation and/or return a message. Another extension called .../Map/ takes two schemas with variables written into them and maps instances of one schema into instances of the other. SHACL leverages the SPIN concept of template queries to provide a standard extensibility. The goal of this is that everyone will have a SPARQL template engine and any extensions that can be coded as SPARQL templates won't require software updates to execute. Expressivity: If you take extensibility into account, both languages are essentially infinite. When you focus at what is available “out of the box” ShEx and SHACL’s logical operators (AND/OR/NOT) and triple constraints are similar but there are several features that are unique to each approach: Aside from that, ShEx and SHACL’s logical operators (AND/OR/NOT) and triple constraints are similar but there are several features that are unique to each approach: * regular partition semantics (optional groups, n-ary disjunctions): ShEx * uniqueness of language tags: SHACL (though this is addressed in a more general sense in the accessors branch which has a ShEx 2.1 milestone). * value sets comprised of IRIs, Literals and Language Tags (matching any literal with that language tag) as well as substrings of them: ShEx While the remainder of the functionality is identical, how it is represented varies: Most of the ShEx value set functionality can be translated to SHACL using Not and schema facets, or SPARQL templates to implement language tag functions. It would be pretty interesting to write such a compiler. I'd be happy to geek with someone on that. I hope this gives some idea of the delta between the two languages. My understanding of SHACL dates back to when I worked on an abstract syntax for SHACL. > Cheers, > John > > -----Original Message----- > From: Gregg Kellogg [mailto:gregg@greggkellogg.net] > Sent: Tuesday, March 28, 2017 10:44 AM > To: W3C Semantic Web IG <semantic-web@w3.org>; public-rdf-shapes@w3.org > Cc: public-shex@w3.org > Subject: ShEx 2.0 Candidate Release > > he ShEx Community Group would like to invite public review of three deliverables: > > Shape Expressions (ShEx) Primer http://shex.io/shex-primer/ > Shape Expressions Language 2.0 http://shex.io/shex-semantics/ > Shape Expressions Test Suite https://github.com/shexSpec/shexTest/ including: > * 337 schemas in three representations: > ShExC: compact syntax > ShExJ: JSON-LD 1.0 syntax > ShExR: Turtle syntax > * 927 validation tests. > * 101 ShExC negative syntax tests > * 7 negative structure tests. > > The test suite has a Implementation Report including 4 of the 5 implementations: > http://shexspec.github.io/shexTest/reports/ > > For feature requests please note the features in the 2.1 milestone: > https://github.com/shexSpec/shex/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.1 > > Many of these have been implemented and tested but are not in this version of the specification. We invite feedback from the community on issues with the documents or tests, new feature prioritization and new feature use cases. > > Comments are welcome on the ShEx Community Group mailing list (archived): > public-shex@w3.org > > Readers may also wish to join the ShEx Community Group: > https://www.w3.org/community/shex/join > > Sincerely, > Andra Waagmeester > Dimitris Kontokostas > Eric Prud'hommeaux > Gregg Kellogg > Harold Solbrig > Iovka Boneva > Jose Emilio Labra Gayo > Karen Coyle > Katherine Thornton > Tom Baker > > > -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.
Received on Wednesday, 29 March 2017 01:09:03 UTC