[OASIS Issue Tracker] (OSLCCORE-118) Resource shapes for versioned type systems

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

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

Nick Crossley commented on OSLCCORE-118:
----------------------------------------

James Amsden added a comment - 14/Jan/16 1:17 PM

This would seem to introduce a different versioning scheme for shapes that does not involve resolving concept URIs in the context of specified configurations. Looking at each issue above: 

1. OSLC Core doesn’t support versioned shapes 

Core doesn’t and shouldn’t address versioning, CCM does. Servers can choose to use CCM to version shapes and applicable resources. If shapes are versioned, then changes to shapes apply to all applicable resources in that configuration. If shapes are not versioned, then changes to shapes apply to all applicable resources in all configurations. There are QoS implications for this, but CCM provides a standard way of addressing versioned shapes. 

2. OSLC doesn’t represent any means of representing provenance in shapes. 

Some provenance information is provided by OSLC Core common properties defined by Dublin Core, and can be included in shapes. However the version history of shapes is provided by CCM implementations. OSLC Core should not define an overlapping and incompatible means of capturing versioning history of resources or shapes. 

3. Shapes have no means of indicating if a property is historic or current 

Again, versioning of shapes should be orthogonal to the properties of the shape. Unversioned shapes have to constrain all applicable resources across all configurations. Versioned shapes are resolved in the same context as the referencing versioned resources. 

Unversioned queries or reports that were created with one configuration of shapes and resources cannot expect to be reliably executed against other configurations of those shapes and resources. This issue can be mitigated by: 

- Have general purpose queries that need to execute across configurations constrained to more stable OSLC domain shapes, or container template shapes established when the container is created. 
- Have administrators modify shapes in upward compatible ways. 
- Servers can provide a facility for merging versions of shapes across all configurations (essentially creating the common unversioned shape described above) so that unversioned queries can be created and executed more reliably across different configurations. Servers may choose to be lax in reporting execution errors in such queries if properties referenced in the query are not available in the current shapes. 

Mixing versioned and unversioned world views is fraught with issues. Implementers and users may find it easier to implement full versioning support for queries, reports, shapes and resources, that to attempt to address the unpredictable special cases that might result from mixed systems. But I do see that having queries and reports be coupled to individual configurations is also a problem.

> Resource shapes for versioned type systems
> ------------------------------------------
>
>                 Key: OSLCCORE-118
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-118
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>          Components: Configuration Management
>            Reporter: David Honey
>            Priority: Minor
>
> 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)