Compact Syntax? - Fwd: [RDF AP] Update on RDF validation at W3C

Forwarding this FYI. The Compact Syntax is once again enumerated as a 
selling point for ShEx over SHACL. I believe we could at a later stage 
still produce a Compact Syntax as a WG note... if anybody has resources 
to work on such a thing (ducking away). Such a syntax could be inspired 
by ShEx, as long as we don't confuse people about the differences in 
semantics. Or it could be a compact JSON such as

{
     "prefixes" : {
         "ex" : "http://example.org/ns"
     },
     "ex:PersonShape" : {
         "ex:ssn" : "[0..1] string",
         "ex:child" : "[0..*] IRI ex:Person",
         "^ex:child" : "[0..2]"
     }
}

Holger



-------- Forwarded Message --------
Subject:  [RDF AP] Update on RDF validation at W3C
Date:  Wed, 8 Feb 2017 11:05:52 -0800
From:  Karen Coyle <kcoyle@KCOYLE.NET>
Reply-To:  DCMI Architecture Forum <DC-ARCHITECTURE@JISCMAIL.AC.UK>
To:  DC-ARCHITECTURE@JISCMAIL.AC.UK



This is to bring you all up to date with the DCMI involvement in the W3C
RDF validation activities.

DCMI is no longer participating in the W3C working group that is
developing SHACL.[1] The group tried for two and a half years to
reconcile the requirement for a basic vocabulary for RDF validation with
some business use cases that need to be implemented through complex
SPARQL functionality. There was a stated goal to use the Shape
Expressions (ShEx) vocabulary [2] as a more user-friendly entry to
SHACL, but this did not occur. Instead, there is now a separate
community group for ShEx [3], and various of us are following that for
DCMI. SHACL development continues, with an emphasis on SPARQL as an
implementation language. We'll see in the next few months if it is on
track to become a W3C standard.

As Kai and Thomas showed in their paper for DC 2015 [4], there are
advantages to having multiple options for RDF constraint languages that
can be tested through SPARQL. Both SHACL and ShEx can be transformed to
SPARQL queries, and both are expected to have full test suites. SHACL
has been implemented in TopQuadrant's TopBraid software,[5] and ShEx has
a number of open source implementations.[6]

With both languages fairly well developed, this seems to be an opportune
time to see if either or both can be used to implement the DSP, or a new
version of the DSP.[7] Having followed this work I am now more aware of
what the DSP lacks (such as or/not/and, and gt/lt functions). It would
be useful to do a comparison of the DSP with the functionality that ShEx
and SHACL provide. Note that at the moment neither the ShEx nor the
SHACL communities use their code to provide the kind of documentation
that was envisioned with the Singapore Framework [8] and the DC
Application Profiles.

I started a kind of "think piece" on github [9] attempting to define a
range of design patterns that might inform additional work. I have also
created the very bare bones of a table to compare DSP/ShEx/SHACL
functions.[10] I will try to get further on those in the upcoming weeks,
and welcome any collaboration you wish to provide.

kc

[1] https://www.w3.org/2014/data-shapes/wiki/Main_Page
[2] http://shex.io/
[3] https://www.w3.org/community/shex/
[4] http://dcevents.dublincore.org/IntConf/dc-2015/paper/view/386
[5]
http://www.topquadrant.com/2016/09/12/shacl-topbraid-web-products-evn-edg/
[6] http://shex.io/
[7] http://dublincore.org/documents/dc-dsp/
[8] http://dublincore.org/documents/singapore-framework/
[9] https://github.com/kcoyle/RDF-AP/blob/master/Patterns.md
[10] https://github.com/kcoyle/RDF-AP/blob/master/DSPcompare.md
-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600