[OASIS Issue Tracker] (OSLCCCM-19) Resource shapes for versioned type systems

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCCM-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61596#comment-61596 ] 

David Honey commented on OSLCCCM-19:
------------------------------------

Another aspect of the problem we are trying to address is this. Imagine that artifacts are indexed in an indexing provider (for example, Rational's Lifecycle Query Engine (LQE). A query builder wants to determine what properties are relevant to a resource of some RDF type in a known project area. The query builder therefore needs to determine that data from resource shapes. In turn, this requires that resource shapes for querying are also tracked resources and indexed in LQE. However, it is possible that there are multiple resource shapes serving different purposes. For example, in a given project area, you might want a resource shape representing the latest state of type definition resources so that an application can discover that is valid to include in a PUT or POST. For a query builder, it wants a resource shape representing not only the current state, but a union of historic states. However, there is no means to distinguish these different types of resource shapes. One way of addressing this is to have a resource shape that can serve both purposes. If a shape can represent the current state, and prior states, then only one resource shape per project area need be exposed to and indexed in LQE. The same applies to resource instance shapes.

> Resource shapes for versioned type systems
> ------------------------------------------
>
>                 Key: OSLCCCM-19
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-19
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Improvement
>            Reporter: David Honey
>
> OSLC Core defines a number of different types of resource shapes:
> 1) A shape referenced in a creation factory.
> 2) A shape referenced in a query capability
> 3) A shape referenced by a specific instance of a resource
> The problem arises when a type system is versioned and artifacts can have properties defined by some state of that type system. Typically, the shape in the creation factory would define its OSLC properties based on the current state of type definitions. However, the shape for a query capability often needs to satisfy a requirement to support querying and reporting on historic data. Currently, OSLC Core does not provide any means of representing versioned shapes or OSLC properties. Some implementations have attempted to address this by representing multiple OSLC properties and then using owl:sameAs. However, this approach does not allow an OSLC client to distinguish a current property from historical ones that are related to the current one with owl:sameAs.
> If an OSLC client wants to provide a query interface to select properties and values, it will typically want to show the current label of a property in its interface, but when querying, use all the predicates associated with all the versions of that OSLC property. OSLC does not currently define any means of representing provenance in shapes.
> Similarly, there is a requirement for an OSLC client to discover a property whose type definition used to exist or be available, even though currently it is not allowed on new resources. Currently, a resource shape might include an oslc:Property for it, but cannot provide any means of indicating that it is historic versus being a current property.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)