Re: Stand-alone Shapes and oslc:valueRange implemented in SPIN

On 11/26/2014 8:04, Eric Prud'hommeaux wrote:
> I think you mean oslc:valueShape, or at least that's what I see in
>    http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#valueShape

Oops yes, this was my intention. I am attaching an updated version of 
the Turtle files.


> Or someone could parse the shapes and compile an inclusive SPARQL 
> query directly. 

Yes, that could work, if all we want to do get is a boolean result. With 
a magic property we could produce detailed error messages from the 
"inside" of the shape. I had last week introduced spin:violationDetail 
for that, allowing constraint violations to point at other violation 
reports with details.

>
> It may be a bit hard to know how easy this really is until we figure
> out the language. For instance, are the cardinality constraints
> qualified or unqualified?  The feedback I heard on day 1 of the F2F
> was that they are qualified so multiple declarations of dc:creator
>
>    <S> a rs:ResourceShape ;
>        rs:property [
>            rs:name "creator" ;
>            rs:propertyDefinition dc:creator ;
>            rs:valueShape <Authority> ;
>            rs:occurs rs:Exactly-one ;
>        ] ;
>        rs:property [
>            rs:name "creator" ;
>            rs:propertyDefinition dc:creator ;
>            rs:valueShape <Author> ;
>            rs:occurs rs:Exactly-one ;
>        ] ;
>    .
>
> would mean that one of each was required and, implicitly, no others.

I would keep cardinality and value shape separate here, i.e. I prefer 
unqualified. The scenario above would make the data structure very 
difficult to handle by tools like input forms and would be difficult to 
explain to users, esp if something like rs:property is being used. E.g. 
would the above mean that there are two different values for dc:creator, 
or can they overlap. IMHO valueShape should be one condition that is 
tested separately from the other conditions.

>
> I think the big issues with shapes as types were
>    1 contextual constraints (which this addresses).
>    2 conflicting constraints.
>
> I know that your position on 2 is that they can be written in separate
> RDF graphs and responding to that thread had responding to this as a
> prerequisite. I'll respond to the other now.

I believe the SPIN extension that I have written up is also very close 
to solving 2. Like with the suggested Shapes vocabularies, the 
constraint checker could be supplied with "starting point" metadata 
(e.g. a new property), and that starting point could be a Shape that is 
unrelated to the direct rdf:type. The solution with named graphs is an 
alternative to that, for some use cases.

Thanks for your feedback, I sense we have made a breakthrough that 
really combines the best of both worlds.

Holger