Questions on OSLC Discovery 3.0 (review fragment)

[Ian Green1 <ian.green@uk.ibm.com>]

Hello

I'm reviewing https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/discovery.html
as 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.

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 


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?

Creation factories

Section 5.4 describes how an
LDPC advertises "the rdf:type
of 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.

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. 

The LDPC wording in section 4.2.1.6
might 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?

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.

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.

Appendix A.3
Typo: Description: "An LDPC whose .... spurious
quotation mark.

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