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