HistoryViewLinks to this page 2013 December 13 | 08:26 am

This page is part of Actions 2.0 Scenarios.

These scenarios cover the case where a consumer wants to consume actions from any resource (i.e. “generically”), without being tied to a particular domain or implementation profile.

Scenario: OSLC explorer

This scenario describes a client that is designed to allow a user to explore OSLC data (and maybe wider non-OSLC linked data) irrespective of its domain. Once configured with the service provider catalog, it allows the user to navigate the provider’s service providers, query capabilities and selection dialogs in order to find resources. Once a resource has been found, it allows the user to see a summary of that resource (using standard dcterms/rdfs/common oslc/ldp properties, e.g. dcterms:title, rdfs:label, oslc:icon), the option to see its other representations (HTML representation, small & large previews), drill down to the RDF triples (for those it doesn’t know how to render), or follow links to other linked data resources.

Actions: the user (a human), the consumer (The OSLC explorer app), the provider (the provider being explored).

Prerequisite: the consumer has been configured with a provider’s URL.

  1. The user chooses a service provider and selection dialog.
  2. The consumer displays that dialog to the user.
  3. The user selects a resource and submits the dialog.
  4. The consumer looks up that resource, and displays a summary of it to the user based on the common properties used that it understands.
    • This includes the consumer displaying a button for each of the Actions resources exposed by that resource (as it considers Actions to be part of the “common properties”).
  5. The user clicks a button to execute that action on that resource.
  6. The consumer follows the instructions in the Action resource to execute the action. (It is programmed to support the full set of interaction patterns/profiles that were defined as part of the original spec - and therefore any that extend these and are compatible - therefore it is likely to be able to execute most actions it comes across except proprietary or future non-compatible additions).