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