[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=67788#comment-67788 ] 

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

James Amsden added a comment - 23/May/16 6:00 AM

Any OSLC domain consists of a vocabulary of terms and shapes that constrain those vocabularies according to the needs of the domain.

Instances of OSLC domains are instances of these vocabulary terms and should adhere to the constraints for the vocabulary and any additional constraints applied by the server controlling the resources that are required to support the use of a domain in a context. 

There can be many different usages of the same domain, each having its own usage specific constraining shapes. These could be considered variants of the domain for specific purposes and different variants may have incompatible constraints. 

In addition, domain vocabularies and shapes may change over time, or more likely, be extended by tool vendors and end users. These could be considered versions of the domain. 

These different versions and variants of the domain vocabulary and constraining shapes need to be managed in configurations with their associated instance data. This could be done by having a global configuration that included contribution from the domain vocabularies and shapes as well as contribution of instance data. 

Queries would generally be done in the context of a particular configuration in order to ensure the data and metadata are a consistent configuration. Queries that need to go across history present a particular challenge because the changes in vocabulary and shapes are unpredictable and may not be able to be merged in any consistent, reliable, or repeatable way.

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