Getting into Shapes: OSLC 3 step program

There have been many scenarios since the inception of OSLC that have hinted at various needs around the ability to describe resources either that exist or don't, or if you do exist, there are many of them that are similar.  So looks take a look at what drove OSLC specification to create the concept of Resource Shapes to support these scenarios and what these Shapes look like.

• Creation
  Perhaps the most commonly requested scenario that supports the need for Shapes.  Resource creation can also be accomplished by leveraging delegated Web UIs that hide the complexity of rules for submission for a successful resource creation.  This supports programmatic creation of resources driven by processes that run and create resources, like monitoring applications and finding problems, then automatically logging them.
  Shape location: within service provider definition of the creation factory.

• Query
  Often is the case that we need to find something. We can always navigate from a hierarchy of folders into subfolders or using tags, though this only gets us so far.  Many of the services that are exposed have differing data models and these need to be exposed to support a meaningful query.  Intelligent query builders can be written and used, select what the criteria to search on and to define what resources and properties to deliver in the response.
  Shape location: within service provider definition of the query capability.

• Modify
  For any resource in hand (or the URI for the resource and a representation of it), we'd like to know what are the allowed properties and property values.  Though in open systems, the shape associated with a given resource could change over time, depend on some values of properties or even based on which user is currently accessing the resource and its shape.
  Shape location: property oslc:instanceShape on subject resource.

If you look hard in other places, you see Shapes referenced from Shapes and you can see Shapes also can be useful for some other purposes.  For example, the Shape associated with the Modify scenario could be used to build a simple resource viewer based on value types and number of occurrences of some properties.

The current model for Resource Shapes continues down the model we've been follow at OSLC, just enough specification to support our scenarios.  The shapes provide some key capabilities for describing resources: allow properties, the number of them, any range restrictions, required-ness, readonly-ness, allow values and so on.   Implementations are started to surface that support these scenarios and we look forward to getting feedback on this support.