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] Questions on OSLC Discovery 3.0 (review fragment)

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

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>


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 | ServiceProvider
                        "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 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 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, 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.
best wishes,

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