[OASIS Issue Tracker] (OSLCCORE-23) Should a ServiceProviderCatalog or ServiceProvider resource be an LDPC?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60362#comment-60362 ] 

Martin Pain  commented on OSLCCORE-23:
--------------------------------------

1. I have three thoughts on the problem of ServiceProviderCatalog and ServiceProvider resources having to include ldp:contains triples:

a) If they include the ldp:contains triples, that will at most double the number of triples. This is because we need the membership triples to be in the representation anyway, as otherwise you can't discover the URIs that you're trying to discover. At worst, making them LDPCs requires that membership triple to be duplicated by an ldp:contains triple. I wouldn't really want that, but it's not like we're increasing it exponentially.

b) Where is the requirement from LDP to include the ldp:contains triples stated? I can't find it.

c) LDP spec section 5.4.2 (HTTP POST on Direct containers) says "A LDP Direct Container's membership triples MAY also be modified via through other means [than creation of contained LDPRs via POST]". The definition of "containment" (section 2 "terminology") says "The relationship binding an LDPC to LDPRs whose lifecycle it controls and is aware of". Taking these two statements on their own, it sounds like IF the LDPC's members were NOT created via POSTing to the LDPC (i.e. the LDPC does not control their lifecycle), then the LDPC does not need to have ldp:contains links to them (the membership triples can be modified [created] by another means that does NOT also create an ldp:contains triple). This may well have not been the intention of the spec. This has the obvious side-effect of not being interoperable with LDP clients that are relying on containment triples, and that are not reading the membership triples. But on my scanning through the LDP spec just now appears to be a way by which LDPCs don't need to have containment triples.

2. On Service resources being LDPCs. If we're replacing Query Capabilities and Creation Factories with a GET or POST, respectively, to an LDPC, then the service must at least have an LDPC for each type it contains. (We need to address, as part of v3 discovery, outside of this ticket, how clients discover those containers). I'm happy with the Service resource itself not being an LDPC (unless the server implementation decides to make it one).

> Should a ServiceProviderCatalog or ServiceProvider resource be an LDPC?
> -----------------------------------------------------------------------
>
>                 Key: OSLCCORE-23
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-23
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> OSLC 2.0/3.0 compatibility re-introduces the OSLC Core 2.0 ServiceProviderCatalog (SPC), ServiceProvider (SP) and Service resources. These resources provide a somewhat static, up-front discovery capability to access information about OSLC resources and capabilities supported by a server.
> OSLC Core 3.0 also utilizes Link headers in response to OPTIONS or HEAD request on LDPCs to dynamically discover information about OSLC resources and capabilities supported through that LDPC. 
> Although these are somewhat overlapping approaches to discovery, they are both useful in practice and can be complimentary, balancing the convenience of up-front static discovery by parsing a few resources, and more dynamic, flexible discovery through introspection of LDPCs. In any case, the OSLC Core 2.0 discovery approach is required for compatibility.
> There may be a way to normalize these by requiring that ServiceProviderCatalog, ServiceProvider and Service resources are also LDPCs. This may allow server implementations to dynamically generate the service provider resources from the LDPC and may simplify the server implementation of OSLC Discovery, and eliminate data redundancy.
> However, there's a potential problem with 2.0 SPC and SP's being LDPCs. A GET on an LDPC must also return the contents of the container in the ldp:contains property of the RDFSource resource response body. That may be a large amount of data for any given LDPC that would be inappropriate for SPC discovery. LDP supports the use of the Prefer request header to allow the client to give the server a hint on what content is desired in the response, and possibly the omit-parameter with ldp#PrefereContainment could be used to get the LDPC without any of its content element URIs. However, an OSLC 2.0 client would not know anything about these headers.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)