All,
It seems that many of us are in other meetings this week, or otherwise
unavailable, so it makes sense to use asyncronous communication until we
can all get together again.
I want to bring the group up to date on the W3C Shapes work, however.
The group will soon be offering the SHACL specification as a First
Published Working Draft.[1] The draft is not (NOT!) an easy read, and
I've only recently been made aware of some assumptions in the draft that
were not at all obvious to me. It will be VERY important that DCMI do a
good read of the draft and make comments.
The draft, in large part, represents an implementation of a SPARQL-based
validation engine created in TopBraid software. It uses some concepts
from OWL. There is, as yet, no user guide. There are, however, numerous
test examples that might help give you an idea of what SHACL code looks
like.[2] Unfortunately, the examples don't have comments, so it isn't
always clear what is being test. (And could someone look at this and
tell me if read access is open to w3c's github area.)
For our part, we need to submit tests. This will be tricky because none
of us is able to write SHACL, but what I intend is for us to provide
tests with documentation so that SHACL code can be written for it. In
particular, we need to provide tests that illustrate our rather "messy"
world. Some cases that I have provided have been met with incredulity by
the W3C group members, since they all work in highly controlled closed
worlds. This simple example led to a lengthy discussion[3]:
<bf_Person1>
bf:identifiedBy <http://id.loc.gov/authorities/names/n80103961#RWO> ;
bf:identifiedBy <https://viaf.org/viaf/268367832/#Knape,_Joachim> .
rule: at least one id.loc.gov, zero or more viaf.org*
We also seem to be the only ones who need to de-reference IRIs in order
to complete validation. (I was subjected to a rather vehement suggestion
that every library application should just hold its own copy of
everything at id.loc.gov for purposes of validation.) In addition, there
is the question of whether constraints operate on an open or a closed
graph. An open graph would be "must have these properties but may have
others" and closed would be "only these properties."
I will create a directory in the test area for our examples. Examples
need to be in turtle. Alternately, if you have documentation that
includes your validation rules, I can try to develop dummy tests from that.
I need to run now, but I'll probably contact some of you individually in
the next week or so to get this going. I'm on the road, but am connected
except for early next week.
If you can, PLEASE at least look at the draft SHACL document to form a
first impression.
Thanks,
kc
[1] Currently: http://w3c.github.io/data-shapes/shacl/
[2]
https://github.com/w3c/data-shapes/tree/gh-pages/data-shapes-test-suite/tests/features/core
[3]
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Sep/0107.html
*The solution to this in SHACL uses qualified constraints, as in OWL:
ex:MyShape
a sh:Shape ;
sh:property [
sh:predicate bf:identifiedBy ;
sh:qualifiedMinCount 1 ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedValueShape [
sh:constraint [
a sh:URIPatternConstraint ;
sh:uriPattern "^http://id.loc.gov" ;
] ;
] ;
] ;
sh:property [
sh:predicate bf:identifiedBy ;
sh:qualifiedMinCount 1 ;
sh:qualifiedValueShape [
sh:constraint [
a sh:URIPatternConstraint ;
sh:uriPattern "^http://viaf.org" ;
] ;
] ;
] .
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|