Presentation Proposal for LDP Workshop on April 21st

Hi,

We are exploring the application of Linked Data Platform (LDP) in Oracle
Fusion Applications such as Workforce Reputation Management, HCMConnect and
Wellness. The motivation for using LDP in these Fusion Applications is to
address the data integration challenge and to provide an abstraction for
vendor specific APIs through a standards compliant interface.

In our efforts in implementing LDP, we have come across some limitations in
the current recommendation. We would like to discuss these limitations, and
proposals to overcome them as outlined below, at the workshop.

1. Provisions for Access Control, Authorization, and Usage Policies: We
propose to include 'ldp:ProtectedContainer'/'ldp:ProtectedResource' to
indicate that a container/resource is subject to a policy, and/or the
property 'ldp:policy' to identify that policy. The policy will be evaluated
based on the attributes presented in the auth token in the HTTP request.
The LDP server may send a redirect to a public representation of the
resource with an optional explanation in RDF when the policy is not met.

2. Multiple Containment Hierarchies: In the current LDP recommendation, a
container and a resource have a 1:1 relationship, i.e. only one parent
container per child resource. However, a concept (LDP resource or child
container) can be grouped under different categories (LDP containers).
There should be provisions in the LDP recommendation to handle these
alternate containment options.

3. Back-links: For container discovery, it is beneficial to include an
inverse functional property for 'ldp:contains'. For example, back-links are
very useful when a child container does not have a policy attached and is
subjected to the parent's policy.

4. Push Capabilities: An application server (consumer) might be interested
in getting updates on the future states of an LDP resource without issuing
frequent HTTP get requests. To facilitate this scenario, the consumer can
insert a triple on the resource specifying that it is an 'ldp:observer'.
The LDP server can send HTTP post requests to the endpoints identified by
'ldp:observer' as it receives updates on the observed resource.

5. Client-Directed Paging: The LDP Paging recommendation supports only
server-controlled paging. We suggest LDP add support for client-directed
paging so that client requests will have more control over the HTTP
response payload.

6. Resource Filtering Semantics: The prefix 'Prefer' in the containment,
membership and minimal-container triples, for example
'PreferMinimalContainer', can be confusing when used with the 'omit'
parameter in the HTTP prefer header. Therefore, we suggest removing the
prefix 'Prefer' from the LDP terms used for resource filtering.
Furthermore, the LDP recommendation should include additional membership
filter conditions such as 'ChildContainers', 'BinaryResources', etc.

Looking forward to the workshop tomorrow!

Thanks,
Oshani Seneviratne