Re: Validation entry points

On 1/25/15, 6:37 PM, Dimitris Kontokostas wrote:
>
>
> On Sun, Jan 25, 2015 at 6:06 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>
>     On 1/24/15, 11:36 PM, Dimitris Kontokostas wrote:
>
>         I think this is getting off-topic and leaning towards
>         constraint discovery. In the same way one can define different
>         (ShExC/RS)shapes in different datasets one can also define
>         different class constraints in different datasets.
>
>         I think Holger's point was about the constraint definition. As
>         also Peter pointed out we have requirements for three types of
>         constraints
>         1) Constraints on instances of a class
>         2) Global constraints and
>         3) Shape constraints in the way ShEXc & RS define them
>         Holger's suggestion probably has good coverage for 1 & 2 but
>         needs further input for 3.
>
>
>     Yes, exactly. I need more input on how the stand-alone shapes are
>     supposed to be used. This takes us to the question how does the
>     validation start. LDOM has two starting points:
>
>
> IMHO we should make the validation entry point flexible enough to 
> handle different cases both for the current requirements and for 
> future extensions.

Yes absolutely.

> Maybe it is easier if, for now, we focused only on how one can define 
> different types of constraints. The RS submission does something 
> similar and focuses mainly on the shape definitions.
> Of course I might be wrong here so feel free to correct me.

I primarily want to understand the role of oslc:instanceShape. This 
seems to be one of the last remaining features of RS/ShEx not yet 
covered by LDOM (unless we use rdf:type). This property seems to be 
instructive for engines, so we need to make sure that the use cases of 
those engines are covered. That's all I need right now.

Holger