Re: Presentation Proposal for LDP Workshop on April 21st

Hi,

Here is my presentation.

Cheers,
Oshani

On Mon, Apr 20, 2015 at 12:03 PM, Oshani Seneviratne <oshanis@gmail.com>
wrote:

> 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
>
>