Hi Karen,
> 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.
I think it could fly, as many rules are indeed specific to classes used in the context of the application.
But I agree with your analysis of disadvantage. I think that as a minimum, a shape could also be attached to properties, in case the constraint is more directly attached to a property (see below).
Actually it could be safer to enable attaching shapes to any resources.
I suspect that some people will say any case can be solved by creating 'technical' classes (e.g. "the class of all resources that are subject of a skos:prefLabel statement"). But this wouldn't make things intuitive, if the shapes language assume everyone to do so.
>
> 2. In data you curate, would classes accurately pinpoint validation targets?
Very often yes, but there will be exceptions, like SKOS' S14: "A resource has no more than one value of skos:prefLabel per language tag."
http://www.w3.org/TR/skos-reference/#L1567
>
> 3. Anything you want to say about treating shapes themselves as classes to be used in instance data?
Using classes to represent shapes would at least require a new mechanism to relate these classes to the graphs where they 'apply' (i.e. the graphs where the specified constraint should hold). I'm not sure it's really great from the general perspective of RDFS/OWL as knowledge representation languages. I.e. we would restrict the scope of some classes to certain graphs, while RDFS/OWL classes have been defined with an open world assumption since the beginning.
Antoine
On 2/14/15 9:20 PM, Karen Coyle wrote:
> 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
>
|