Assuming that the weather calms down in Boston, as it is supposed to, I
will be at the W3C shapes meeting there. The group is heading off in
some odd directions and hopefully at this meeting some decisions will be
made. There is one question that I want to run by you.
One of the long discussions that has gone on in various threads has been
the relationship of shapes (which are defined as sets of validation
rules applied over a graph) and rdfs classes.[1] There is a strong
contingent that not only sees class membership as the primary trigger
for shapes, but also has suggested that shapes be defined as classes so
that they can be used in instance data to defined graphs for validation.
[Note: "shapes" are analogous to a DSP description template. They define
properties with cardinality, value constraints, etc.]
In the first aspect, classes as shapes, one would apply validation to
graphs based on rdf:type declarations. For example, "a foaf:Person"
would be the trigger to apply a particular set of validation rules to a
graph. (Warning: potentially funky code ahead. Go for concepts not
accuracy!)
##shape##
ldom:PersonShape
a ldom:Shape [
ldom:target foaf:Person ;
ldom:predicate foaf:name ;
ldom:minCount 1 ;
] .
##instance data##
me:myData a foaf:Person ;
foaf:name <some value> .
The second proposal would mean that validation rules (shapes) would be
defined as a class, and the class would be used in instance data to
indicate where the shape rules would apply. The example given goes
something like:
##shape##
ex:BookShape
a ldom:Shape ;
ldom:titleRule [
ldom:predicate dct:title ;
ldom:minCount 1 ;
] .
##instance data##
me:myData a ex:BookShape ;
dct:title <some value> .
I see advantages and disadvantages to each, but want to represent your
thinking at the meeting.
#1 advantages: many sets of triples are already defined with classes,
and this takes advantage of that
disadvantages: not all data uses classes where validation is desired;
this would encourage assigning classes with validation in mind, rather
than semantics; not easily used in mashups where classes do not match.
#2 advantages: ok, I'm not seeing any at the moment
disadvantages: requires data creators to be aware of a particular
validation need and to code that in the instance data; shapes as classes
may be orthogonal to desired data semantics; not easily used for
"foreign data" that isn't coded with shape classes; greatly limits
re-usability (same data, different use case, like input and export).
My questions are:
1. How do you feel about marrying shapes to classes, in the #1 form? Any
data without classes will be approached only with global validation rules.
2. In data you curate, would classes accurately pinpoint validation targets?
3. Anything you want to say about treating shapes themselves as classes
to be used in instance data?
Thanks for any advice you can give. Also, if you have any data that
illustrates your thinking on this, please send me examples.
kc
[1]
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jan/0223.html
But also other threads in:
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Feb/thread.html
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jan/thread.html
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2014Nov/0022.html
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|