RE: [oslc-core] OR semantics of applicable shapes for oslc:resourceShape

["Nick Crossley" <ncrossley@us.ibm.com>]

Martin brings up the use case for extending base OSLC definitions with vendor or installation specific properties. This is a commonly raised use case, but it is not clear to me that multiple instance shapes is the right way to do this. Martin raised one issue with such extension, when trying to override a base property definition - we could resolve that by saying that tool-specific extensions could not conflict with the base shape, but only add new properties and further restrict existing ones.

I think Ian has summarized the scenarios for creation factories (and by extension query capabilities and LDPCs) having disjunctive shapes, and valueShape having conjunctive shapes: we can specify that in the relevant property definitions for creation factories, query capabilities, appropriate LDPCs, and valueShape.

For shapes that apply to a resource via oslc:describes and the rdf:type, it seems that conjunctive logic would apply, following the same argument as valueShape.

That leaves instanceShape. It seems to me that there are possible use cases for any form of combination of multiple such shapes, but that no specific simple interpretation satisfies all those use cases. As Ian mentioned, a provider can construct an appropriate shape reflecting the current state of any resource, good for read access. If the shape is to be used to indicate the possible properties and their values on a PUT, then indeed a server might want to indicate some complex boolean logic of the form described by Martin.

Are the semantics for instanceShape something we should leave undefined? Or do we think it important to get the semantics of shapes complete for 3.0? Do we want to define a completely new mechanism for shape extension? Or do we leave all these complications to be addressed in a future OSLC standard referencing work by the W3C Shapes group?

Nick.

"Sarabura, Martin" ---03/04/2016 07:24:08 AM---I don't think I can express my thoughts as eloquently as Ian did below, but I will try. What I'm hea

From: "Sarabura, Martin" <msarabura@ptc.com>
To: Ian Green1 <ian.green@uk.ibm.com>, Jim Amsden/Raleigh/IBM@IBMUS
Cc: "OASIS OSLC Core TC Discussion List (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Date: 03/04/2016 07:24 AM
Subject: RE: [oslc-core] OR semantics of applicable shapes for oslc:resourceShape
Sent by: <oslc-core@lists.oasis-open.org>

---

I don't think I can express my thoughts as eloquently as Ian did below, but I will try.
 
What I'm hearing so far is that we have multiple competing requirements:
1. Ability to specify for a single service one shape for the request and one for the response.
2. Ability to OR shapes so that any one of those shapes is valid (disjunctive, referred to as OR semantics in the document)
3. Ability to union shapes together so that the conjunction of all shapes is the valid shape (referred to as AND semantics in the document)
 
I have some trouble with #3 in that it requires an inherent ordering in cases where a particular property is overridden in one of the sub-shapes to mean something different. For example, one sub-shape could specify the cardinality of a property to be zero-or-one and another could specify zero-or-many, and the expectation is that the second one overrides the first one. So that's one issue.
 
But by cracking open this Pandora's box I see another potential issue, which is that an implementation may wish to combine 2 and 3, as in
 
shape = (a && b && c) || (a && d) || e
 
where a, b, ... are shapes, && is conjunction and || is disjunction. And then we can combine this with 1 to get multiple shapes, each potentially expressed as a combinations of conjunctions and disjunctions. I don't have a recommendation for how we can accommodate these scenarios so I throw it out to all members to consider.
 
What I don't want to happen is to shut down the possibility of using #3: PTC wants to have a mechanism for #3 so that we can extend the base OSLC definitions with PTC-specific terms, and implementation-specific terms if the customer wishes to do so. Clearly #1 is required, and #2 expresses polymorphism, which is fundamental.
 
Regards,
 
Dr. Martin Sarabura
R&D Fellow, PTC
 
 
 
 
 
From: oslc-core@lists.oasis-open.org [mailto:oslc-core@lists.oasis-open.org] On Behalf Of Ian Green1
Sent: March-04-16 5:02 AM
To: Jim Amsden
Cc: OASIS OSLC Core TC Discussion List (oslc-core@lists.oasis-open.org)
Subject: Re: [oslc-core] OR semantics of applicable shapes for oslc:resourceShape
 
Hi Jim 

The draft currently gives a uniform interpretation of multiple applicable shapes - with your proposed wording they are all ANDed together.  I'm not sure this is correct - it seems to me that we might need both: 

oslc:resourceShape 
For a (eg) CreationFactory, taking resourceShapes conjunctively seems to offer little expressive power - the server could simply form a single shape which expressed this conjunction and so replace several shapes with one. Equally, disjunction could achieved by having more than one CreationFactory, each defining a disjunct. 

Either design seems expressive enough; I'd speculate that it is unlikely for a server to want conjunction within the scope of a single capability, so the disjunctive meaning seems to win to me.  Perhaps our decision should be based on backwards compatibility - we don't want to change the meaning of existing service documents? 

I took a look at one of the implementations I'm working on (an IBM product) and find it is using the disjunctive interpretation. Here is a fragment from a Service document: 

       <oslc:creationFactory> 
          <oslc:CreationFactory> 
            <oslc:resourceShape rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/types/_zA9W4dwGEeWFILYJGTqecQ"/> 
            <oslc:resourceShape rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/types/_zJ4pYdwGEeWFILYJGTqecQ"/> 
            <oslc:resourceShape rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/types/_zIPqodwGEeWFILYJGTqecQ"/> 
            <oslc:resourceType rdf:resource="http://open-services.net/ns/rm#Requirement"/> 
            <oslc:resourceShape rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/types/_y5XhIdwGEeWFILYJGTqecQ"/> 
            <oslc:resourceShape rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/types/_y7dL2dwGEeWFILYJGTqecQ"/> 
            <oslc:resourceShape rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/types/_zC5QkdwGEeWFILYJGTqecQ"/> 
            <dcterms:title rdf:datatype="http://www.w3.org/2001/XMLSchema#string" 
            >Requirement Creation Factory</dcterms:title> 
            <oslc:resourceShape rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/types/_zGnS8dwGEeWFILYJGTqecQ"/> 
            <oslc:creation rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/requirementFactory?projectURL=https%3A%2F%2Fgreenfront.edinburgh.uk.ibm.com%3A9444%2Frdm%2Fprocess%2Fproject-areas%2F_xlT4QNwGEeWFILYJGTqecQ"/> 
            <oslc:usage rdf:resource="http://open-services.net/ns/core#default"/> 
            <oslc:resourceShape rdf:resource="https://greenfront.edinburgh.uk.ibm.com:9444/rdm/types/_y_UYIdwGEeWFILYJGTqecQ"/> 
          </oslc:CreationFactory> 
        </oslc:creationFactory> 

Each resource shape in this factory is (in general) mutually exclusive with respect to the others so this is OR interpretation. 

oslc:instanceShape 
A server has control over the instanceShape triples it puts into named graphs;  the same comments apply here that I made above.  If multiple shapes are associated by instanceShape and a conjunctive interpretation is required, the server can form a single shape that is the conjunction and instead use a single assertion.  Conjuctive interpretation would require work from a client to figure out the "actual" shape. 

A disjunctive interpretation on the other hand is more expressive - there is no alternative _expression_ of disjunction, unlike in the service cababiity case above.  Without a disjunctive interpretation it is not possible for a server to indicate that a resource is polymorphic in the sense that it can have "this shape or that shape".  So it seems to me that if a shape is associated by multiple instanceShapes, the most flexible interpretation is OR.  I'm not aware of this case in any implementation, though. 

oslc:valueShape 
In this case the meaning is conjunctive - each subject shape is making an assertion about the object resource of some property.  The intention is that a valueShape assertion allows a client to "expect" things about that resource's shape.  Given this, multiple shapes associated via valueShape need to be taken conjuctively, so that each of them can be expected to hold. 

Minor comment on the wording in the draft which I've just noticed: 
Service oslc:resourceShape ResourceShape - associates a constraining shape with the entity request or response resource of a service (e.g., a creation or query service). 
Is there a better word than "service" here.  An oslc:Service does not have any such assertions - rather the creation/query/delegated resurces have these assertions. 

best wishes,
   -ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM 

<oslc-core@lists.oasis-open.org> wrote on 03/03/2016 21:34:36:

> From: "Jim Amsden" <jamsden@us.ibm.com> 
> To: "OASIS OSLC Core TC Discussion List (oslc-core@lists.oasis-
> open.org)" <oslc-core@lists.oasis-open.org> 
> Date: 03/03/2016 21:34 
> Subject: [oslc-core] OR semantics of applicable shapes for oslc:resourceShape 
> Sent by: <oslc-core@lists.oasis-open.org> 
> 
> On today's Core TC call, we discussed a resolution to OSLCCORE-44 
> oslc:instanceShape should explicitly allow multiple valuesby simply 
> adding a sentence to the end of the oslc:instanceShape Property 
> indicating a resource may be associated with zero or more shapes.
> 
> But this uncovered another possible issue with the meaning of 
> applicable shapes. The second to the last paragraph in section 6.2 says:
> 
> "If more than one shape applies to a resource then that resource SHOULD
> satisfy all the constraints defined by all the shapes (AND 
> semantics). However, the specification for a service description MAY
> define alternate semantics. For example, a service MAY require that 
> the resource satisfy the constraints defined by at least one of the 
> shapes (OR semantics). "
> 
> This results from a different meaning of the different ways shapes 
> are associated with resources:
> 1. oslc:instanceShape - directly associates a constraining shape 
> with a  resource
> 2. oslc:resourceShape - associates a constraining shpae with the 
> entity request or response resource of a service
> 3. oslc:valueShape - associates a constraining shape with the 
> resource that is the object value of a property of a resource
> 
> The introduction of OR semantics might be because of some confusion 
> caused by the way oslc:resourceShape is described. In the 
> description above, the shape is applicable to the resource produced 
> or consumed by the service. However, the oslc:resourceShape Property
> section describes oslc:resourceShape as "used to link an application
> service description with a shape resource that describes some aspect
> of the service's API contract", describing the resources involved in
> the service, not constraining the actual resources. This perspective
> is implicitly OR semantics since the service might describe more 
> than one resource.
> 
> This could be an unfortunate coupling of the idea of applicable 
> constraints on a resource, and descriptions of resources involved in
> a service. These don't seem like the same thing.
> 
> I suggest the easiest way to resolve this is to simply remove "
> However, the specification for a service description MAY define 
> alternate semantics. For example, a service MAY require that the 
> resource satisfy the constraints defined by at least one of the 
> shapes (OR semantics)." from the second to the last paragraph in section 6.2.
> 
> 
> 
> Jim Amsden, Senior Technical Staff Member
> OSLC and Linked Lifecycle Data
> 919-525-6575

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU