OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]