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
- From: Ian Green1 <ian.green@uk.ibm.com>
- To: "Jim Amsden" <jamsden@us.ibm.com>
- Date: Fri, 4 Mar 2016 10:01:34 +0000
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]