[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-118) Resource shapes for versioned type systems
[ https://issues.oasis-open.org/browse/OSLCCORE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67786#comment-67786 ]
Nick Crossley commented on OSLCCORE-118:
----------------------------------------
David Honey added a comment - 15/Jan/16 3:33 AM
Typically it is not a resource shape that is versioned. It will be type definitions, such as attribute data types, artifact attributes, link types, and artifact types. A resource shape is typically constructed dynamically at run time from all the type resources that apply to an artifact of a specific RDF type. The problem is that OSLC Core does not provide any standard means of representing this. For example, a resource shape must reference a OSLC property using oslc:property and the reference must be inline. OSLC clients will expect to see the data about the property using that reference as a subject.
While I agree that the OSLC CCM domain is relevant here, it is also a core issue. We currently have a real world problem that exists in CLM 6.0.1 that we cannot adequately address in CLM 6.0.2.
Let me restate the requirements we are trying to satisfy:
1) An OSLC client shall be able to determine the representation of an OSLC property as it currently exists, and as it existed at prior points in time as that property definition was changed, and shall be able to determine which is the most recent definition.
2) An OSLC client shall be able to determine the representation of an OSLC property that used to apply to an artifact of some RDF type, but that no longer applies.
We might represent an oslc:Property as an oslc_config:VersionedResource. One issue here is that in at least two implementations I know of, an oslc:Property is constructed from two separate versioned resource. This makes it awkward to represent an oslc:Property as a versioned resource. One might synthesise a set of versions for a property by constructing one for each pair of a specific version of artifact attribute and a specific version of attribute data type over the time instances they changed. That also requires that each version of an oslc:Property has a URI since prov:wasRevisionOf requires a URI reference and cannot be a blank node. This means that an implementation also has to synthesise a URI because there is no oslc:Property resource - it is constructed at run time from two other versioned resources. While this is technically possible it makes the implementation more complex than it might be.
This doesn't solve the 2nd requirement. If a query capability wants to query on historic properties, then the shape needs to include oslc:property statements to properties that might have been eligible for use on an artifact of a specified RDF type at a prior time, but that is no longer valid for either new artifacts, or new values. A resource shape could include an oslc:Property for it, and also declare an RDF type of oslc_config:VersionedResource. By itself, that allows a query builder to discover this historic property. But it cannot determine that this is not currently applicable for new artifacts/OSLC client shall be able to determine the representation of an OSLC propertyroperty values. That's why I suggested the use of oslc:archived.
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]