Re: [oslc-core] Questions on OSLC Discovery 3.0 (review fragment)

["Jim Amsden" <jamsden@us.ibm.com>]

Ian, 
Comments embedded below as usual in
<jra> tags.

Items that may require further discussion:

1. OSLC2 and OSLC3 discovery unification,
any issues?

2. OPTIONS * - normative or removed?


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 Ian Green1 <ian.green@uk.ibm.com>
To:      
 OASIS <oslc-core@lists.oasis-open.org>
Date:      
 02/05/2016 01:35 PM
Subject:    
   [oslc-core]
Questions on OSLC Discovery 3.0 (review fragment)
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

Hello 

I'm reviewing https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/discovery.htmlas at svn 332 but have pretty much got stuck trying to understand the relation
between 2.0-style discovery resources and how things work in 3.0 with LDPCs.
 I take the intention is for 2.0 resources being LDPCs but I don't
see how this can work.  I thought I'd post here to try to clear up
my ignorance - apologies for the noise. 
<jra>There's a few thoughts that might
clear things up:

1. The fact that ServiceProviderCatalog,
ServiceProvider and Service (let's call them "discovery" resources)
are LDPCs has no effect on their OSLC2 compatibility - from the perspective
of OSLC2 they are simply resources with properties. The format of those
resources is constrained by their shape, including the fact that Services
are inlined in their ServiceProvider. This is just a representation, not
an implied implementation.

2. That these discovery resources are LDPCs
also does not constrain servers regarding their LDPC members. Servers could
quite reasonably choose to:

2.1 Create discovery resources in an LDPC
hierarchy and use this only for preserving server configuration information:
ServiceProviderCatalog
        ServiceProviderCatalog
| ServiceProvider
         
      Service
         
              "usage"
LDPC

2.2 Have another completely independent
hierarchy of LDPCs that manage their (possibly many) domain resources.
OSLC3 discovery could be used to reflect on the capabilities of these LDPCs
and the rdf:types they support.

2.3 Have the discovery resources properties
in 2.1 be URIs of the LDPC hierarchy in 2.2. i.e., the Service creationFactory
creation property would be the URI of an LDPC that supports that creation
service.

2.4 Have the catalog resources in 2.1 actually
be the LDPCs  in 2.2 in which case a Service creationFactory creation
URI would be the URI of the Service itself. This combines OSLC 2 and OSLC
3 discovery in the same LDPC resources.

2.5. Not actually manifest the catalog resources
as physical LDPCs, and instead create them dynamically on request from
the server's LDPCs - these are just representations, not necessarily implementations
of the LDPCs. 

2.6. Not have any catalog resources and
only support OSLC 3 link based discovery on LDPCs if OSLC2 client compatibility
is not a requirement. 

3.0. Clients can use discovery with the
catalogs, and/or using OPTIONS/HEAD/GET on LDPCs and examining the link
headers. Either will contain the same fundamental discovery information,
regardless of how the server chooses to organize its resources. The catalog
resources do provide some additional properties, and that's part of the
reason we decided to have them be extensions of LDPCs.</jra>.

I think I understand the creation factory material, and have some comments
on that. 

Section 5 (and Appendices 2-4) 

I'm not understanding how to express a 2.0 style discovery into LDP style.
 Forgive my ignorance here. 

"The members of a ServiceProviderCatalog resource
include ServiceProviderCatalogs and ServiceProvider LDPCs. ServiceProvider
resource members include Service LDPCs. "

Is this use of "member" the same as used in the LDPC spec?  How
can a LDPC contain resources of two different classes (ServiceProviderCatalogs
and ServiceProviders) without using two different LDPCs.  An LDPC
can only have one member relation, but my understanding is that 
<jra>Something missing above? But
yes, this is LDPC membership using the ldp:contains property. An LDPC's
members can be more than one type. LDP doesn't specify how clients discover
what types an LDPC can contain. OSLC 3 discovery, clause 5.4.5 says how
LDPC member types are discovered. Example 2 shows LDPC /bugs/ can contain
Feature and Bug resources. </jra>


Section 5.1 
I don't see how OPTIONS * on a server would return information about a
ServiceProviderCatalogue, at least not in a standard way.  Is there
a need to include this? 
<jra>It was an idea for how clients
could discover root LDPC and/or ServiceProviderCatalog URIs. It can be
removed since we're not actually specifying anything.

Personally I think this is useful and should
have a normative clause that returns a Link header with a relation that
specifies multiple discovery URIs. The reason we didn't do this is because
a server has no way to reflect on extensions that might have been added
in order to be able to report these URIs. But that doesn't mean an Admin
couldn't set them somehow.</jra>

Creation factories 

Section 5.4 describes how an LDPC advertises "the
rdf:typeof resources that can be created in the LDPC".
 The cardinality of this Link rel needs to be zero-or-many, to match
that of oslc:resourceType in Service documents.  Suggest making this
clear. Also, that this is not a constraint on the rdf:types of resources
in the LDPC - it is only a constraint on what resources can be _created_
in that LDPC.
<jra>Added text indicating the LDPC
can contain multiple types, and they may change over time. That link is
zero or many. Its expected the rdf:type values would be derived from LDP
metadata, so it might be reasonably that the members of an LDPC and the
types that can be crated in the LDPC would most likely be the same.</jra>
 

Section 5.5 describes another means to impose constraints, of which
ResourceShape from 2.0 is an example.  (Understood that other constrains
schemes could also be used.) 

There is a need to spell out what multiple such constrainedBy Link rels
would mean.  The natural interpretation (to me) is that _all_ the
constraints would need to be satisfied - a conjunction of all constraints.
 However, this would not sit well with 2.0 useage of ResourceShape.
 In 2.0, creation factories that list more than one ResourceShape
mean disjunction.  I base this only on the wording in the Core
2.0 spec - "A Creation Factory MAY provide
Resource Shapes that describe shapes of resources that may be created.
".It doesn't make practical sense to have multiple ResourceShapes,
each of which, conjunctively, describe the shape of things that can be
created. 
<jra>Agreed, but in the absence of
anything specific from W3C, there's not much more we can say, and this
is language similar to what is currently in LDP. We expect these additional
constraint mechanisms to be defined by LDP (e.g., SHACL), not OSLC. This
is just saying there might be some.

I added a clause to this section to separate
constraint discovery on OPTIONS/HEAD/GET vs violated constraints on POST/PUT.

Regarding multiple constraints, I would
expect that if multiple constraints were applied to the same resource type,
they would be conjunctive. Servers would send Link headers with the resourceType
and constraindBy relations in the same link in order for clients to know
which constraint goes with which resource. There can be multiple Link headers,
one for each rdf:type the LDPC supports. </jra>


The LDPC wording in section 4.2.1.6might suggest that at most one constrainedBy rel can be supplied - any
thoughts on that?  If this were true, the "conjuctive/disjunctive"
issue would be moot, but there would be another issue - how to express
what in 2.0 is multiple ResourceShapes.  If multiple constrainedBys
are permitted, can we ascribe the disjunctive interpretation? 
<jra>Hard to tell if 4.2.1.6 means
at most one constraindedBy, but I doubt it. Link headers can be repeated,
can have multiple rel's and link rel's can take multiple values. My interpretation
is the default is always zero-or-more. This is in part the reason the catalogs
are LDPCs, it allows the OSLC and LDP properties to be merged into the
same resource. So the resourceShape property and constrainedBy property
could both be used.</jra>


There is also to my eye redundancy here between constrainedBy and resourceType.
 Do we want to propagate that in 3.0? I'd like to see a rationalization,
if possible, so that LDPC uses constrainedBy for both oslc:resourceType
and oslc:resourceShape.
<jra>I don't think we should commingle
type and constraints. Type conveys semantic meaning and informs reasoners.
Constraints don't define types or inform reasoners, they constrain the
values of things for a purpose in a context. The resulting confusion between
rdfs:range and oslc:range reflects that cross over between open and closed
worlds, but they are both useful.</jra>
 

I think the wording pertaining to "Update" in this section should
make clear that creation constraints and update constraints are logically
distinct (they may be different) - it is not the case that the LDPC constraint
on POST MUST apply to LDPR PUT.  Example 3 conflates these ideas "...POST
or PUT..." which might not make for a good example. 
<jra>Good point - you sure have a
good eye! Hummmm, Looks like LDP already conflates them - see sectuib 4.2.4.6,
it allows servers to create with PUT. The clause isn't saying the constraints
are the same, only that the same mechanisms are used for create and update
to express the constraints.</jra>

Appendix A.3 
Typo: Description: "An LDPC whose .... spurious quotation mark.
<jra>Fixed</jra>
best wishes,
   -ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM
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