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

I am confused by this example - how do I know that the two constraints
refer to the value of ex:parent?   In this example, there is nothing else
it could apply to, so it is fine, but if there were another :property
constraint in this shape (or none at all), it wouldn't be so clear.  Does
this mean that a shape definition must have exactly one property
constraint?


I'm not sure if the credit/default swap story is really relevant here (we
tend to think of that as a rule instead of a shape, but I'm not sure that
is correct, either).  A credit-default swap is an instrument with (among
other things) two legs (the "premium" and the "contingent").  The legs each
has a currency.  A Mixed-currency one has different currencies for the two
legs.  How would I refer to the two currencies in a single statement in
this form?  I feel as if I need a variable for each of these currencies,
and a way to express ?c1 != ?c2 .





Dean


On Fri, Dec 5, 2014 at 9:29 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 12/5/2014 5:08, Arthur Ryman wrote:
>
>> All values must satisfy the shape pointed to by oslc:valueShape. OSLC has
>> no way to specify that some values must satisfy the shape.
>>
>
> Ok thanks Arthur for clarifying this. So Resource Shapes doesn't seem to
> have a notion of Qualified Cardinalities, while ShEx seems to have that
> (correct me if I am wrong, Eric).
>
> To create a solution that covers all use cases I believe it would be
> helpful to (explicitly) distinguish between
>
> a) structural declarations "which properties are relevant for a
> resource/class"
> b) arbitrary constraints "which additional conditions must be met"
>
> The information from a) would be easy to interpret to drive user
> interfaces, e.g. it would contain the general cardinality and the valueType
> so that suitable input widgets can be selected.
>
> The information from b) would be tested in the background, e.g. to
> validate an input form before it gets submitted.
>
> With this categorization, oslc:valueType would be a single value in
> category a) while there can be any number of valueShapes in category b).
>
> In my current prototyping, I have split spin:constraint into two different
> properties (:property and :constraint) to distinguish between those two
> categories. This also means that there would be something like
>
> ex:Person
>     :property [
>         :predicate ex:parent ;
>         :valueType ex:Person ;
>         :minCount 2 ;
>         :maxCount 2 ;
>     ] ;
>     :constraint [
>         a :ShapeConstraint ;
>         :shape ex:MalePerson ;
>         :minCount 1 ;
>         :maxCount 1 ;
>     ] ;
>     :constraint [
>         a :ShapeConstraint ;
>         :shape ex:FemalePerson ;
>         :minCount 1 ;
>         :maxCount 1 ;
>     ] ;
>
> which means that every Person must have two (biological) parents, one male
> and one female. This distinction between the "global" cardinality of 2 from
> the local qualified cardinalities would allow us to represent QCRs in a
> relatively clean way.
>
> Eric, what do you think?
>
> Holger
>
>
>