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: "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: Wed, 9 Mar 2016 09:15:23 -0500
Ian,
Thanks for the thoughtful analysis.
You and Nick provide valuable insight and experience to this complex discussion.
My point was not to change existing
shape semantics, or to introduce conjunction and disjunction capabilities
into shapes 3.0 - that is being handled by W3C SHACL, and probably something
that should not be addressed by OSLC at this point.
Rather my point is that shapes 3.0 actually
does not give a uniform interpretation of multiple applicable shapes -
it specifies conjunctive semantics, but then allows server to interpret
multiple oslc:resouceShapes for "services" with disjunctive semantics.
I'm not suggesting we change that - rather that we formalize it, treating
oslc:resouceShape for services not as constraints but as metadata describing
the entity request and response bodies of the service operations. Section
"oslc:resouceShape Property" already describes this. My suggestion
was to remove any further mention of disjunctive semantics from the last
paragraph in section 6.2. This results in no change in the specification,
it simply removes an unnecessary and potentially confusing reference to
disjunction in a special case.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From:
Ian Green1 <ian.green@uk.ibm.com>
To:
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 05:04 AM
Subject:
Re: [oslc-core]
OR semantics of applicable shapes for oslc:resourceShape
Sent by:
<oslc-core@lists.oasis-open.org>
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:resourceShapeResourceShape - 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]