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

Holger,

I've looked at your proposal. My summary is that you've defined the 
semantics of the Resource Shape vocabulary in terms of SPIN constraints. 
The result is that you can add oslc:property triples to any owl:Class and 
the SPIN engine will validate the constraints defined in the Resource 
Shape spec. You also allow oslc:valueShape to refer to any owl:Class 
instead of just oslc:ResourceShape instances. This is very elegant. Nice 
work!

I have not reviewed your SPARQL translations for correctness with respect 
to the intention of the Resource Shape spec (which is informal). I hope 
the WG will define a set of common, high level constraints, define their 
precise semantics, and produce equivalent SPARQL, and possibly other, 
translations of them. 

_________________________________________________________
Arthur Ryman
Chief Data Officer
SWG | Rational
905.413.3077 (phone) | 416.939.5063 (cell)
IBM InterConnect 2015




From:   Holger Knublauch <holger@topquadrant.com>
To:     RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
Date:   11/25/2014 06:32 PM
Subject:        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

[attachment "oslc_issue.ttl" deleted by Arthur Ryman/Toronto/IBM] 
[attachment "oslc.spin.ttl" deleted by Arthur Ryman/Toronto/IBM]

Received on Tuesday, 2 December 2014 21:10:08 UTC