This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
PlmHome
>
CoreExtensionsForPlmIssues
(14 May 2012,
GrayBachelor
)
(raw view)
-- Main.GrayBachelor - 13 Mar 2012 ---+++++ Feedback and open issues for the Core Extensions for PLM Updated at 30th April 2012 <u> *OPEN QUESTIONS* </u> %BLUE%Q3 OPEN HOLD%ENDCOLOR% Raised at V1.0: How to identify the versioning behaviour of a resource ?<br /><br />ANSWER: base will have a minimal resource shape, infer from a resource types with no “isVersionOf”, or “replaces”. Multiple approaches today – Service provider doc, Query Header.<br /><br />NOTE: Request guidance from Core. ACTION: Revisit the need once the draft has been updated and identify what gaps existing and if there is a need for alternative behaviours. %BLUE%Q4 CLOSED%ENDCOLOR% at V1.0: What is the preferred use of backlinks for “hasVersion” ?<br /><br />ANSWER: Preferred approach is not to use backlinks, due to referential integrity and the need to handle atomic boundaries. <br />NOTE: hasVersion is not included in the specification. ACTION: Note added that implementation is non-required. However we aim to produce a vocabulary which includes them. %BLUE%Q5 CLOSE%ENDCOLOR% Raised at V1.0: Is there a better dcterms property for succession ?<br /><br />ANSWER: dcterms :replaces is ambiguous, however its definition includes succession so it is proposed as the most applicable term Note there is a W3C workgroup on provenance. [[http://www.w3.org/2011/prov/wiki/Main_Page][W3C Provenance Working Group]] The main concerns identified are for example locating a "latest" version and being able to trace provenance. Concerns have been expressed about the ambiguity of the term replaces when there are multiple branches with advancing tip versions. This could be an example of a type of business indicator used to decorate a version, such as preferrence. ACTION: Position as optional. <u> *OPEN ISSUES* </u> %BLUE%ISSUE 2 %ENDCOLOR%%BLUE%CLOSE %ENDCOLOR%in V1.1 RDFType of Version From John Arwe on resource types 22/11- 13/12 The proposal is to be adopted and then solicit feedback<br /><br />http://open-services.net/pipermail/oslc-plm_open-services.net/2011-November/000065.html<br /><br />and follow on by Mike Loeffler<br /><br />http://open-services.net/pipermail/oslc-plm_open-services.net/2011-December/000069.html Mike Loeffler has prototyped the proposed approach and so it is proposed to adopt the new proposal. Note that Resource type of Version is optional as can be inferred by existence of the "isversionOf" Update the draft Specs to V1.2 Done. %BLUE%ISSUE 3 CLOSE%ENDCOLOR% Raised at V1.0 How to create a new version Description how to create a version- an update will be made to the section on Create Version<br /><br />Comment 3 from John Arwe on createVersion service 22/11<br /><br />http://open-services.net/pipermail/oslc-plm_open-services.net/2011-November/000065.html Mike Loeffler has kindly provided the following input. POST to base resource creation factory service<br />Case1 - If the resource representation does not contain an isVersionOf property, creates a base resource, and if the server supports it, creates the first <br />versioned resource, and returns the base resource URI<br />Case2 - If the representation contains an isVersionOf property with a valid base resource as its target, creates a new version of the base resource, with the replaces resource pointing to the most recently created version (if one exists) PUT to existing base resource<br /> - Updates properties of the existing base resource (no change to existing behavior, except server should reject conversion of a base resource to a version or view) <br />POST to existing base resource (not sure if this is defined in the current spec)<br /> - No new behavior POST to existing version resource (preferred way to create new versions because it explicitly links to previous version of the resource)<br /> - Creates new version of the base resource, pointing to the existing version of the resource as the "replaced" version PUT to existing version resource<br /> - Updates properties of the existing resource (no change to existing behavior, except server should reject conversion of a version to a base or view) ACTION: Treat as implementation example not part of the specification %BLUE%%BLUE%ISSUE 4%ENDCOLOR% OPEN%ENDCOLOR% Raised at V1.0. Comment on and show relationship to the SCM Spec- to be scehduled ACTION: Highligh the SCM integration needs into the reformed Configuration Management Workgroup %BLUE%ISSUE 5 OPEN%ENDCOLOR% Raised at V1.0. RDF examples need updating for V1.1 ACTION: Update with new examples provided by Mike Loeffler %BLUE%ISSUE 7 OPEN %ENDCOLOR%Add description and examples of View <u> *CLOSED QUESTIONS* </u><br />Q1 CLOSED at V1.0: What if my tool provides a versioned container ?<br /><br />ANSWER: The resource version identifies the versioned container<br /><br />Q2 CLOSED at V1.0 : What if my tool doesn’t indicate predecessors ?<br /><br />ANSWER: Indication of succession is a May.<br /><br />Q6: CLOSED at What if the resource supports versioning but has no concept of a base resource ?<br /><br />ANSWER:A base resource is an optional concept, if a resource version does not have a hosting base resource then isVersionOf is used between ResourceVersions<br /><br />NOTE: This approach needs clarification by examples<br /><br />Q7: CLOSED at V1.0 What is a version is hosted by multiple base resources, in the case products when a product version is a member of e.g. different product families<br /><br />ANSWER: isVersionOf refers to the base resource which created the Version. The recommended approach is that the association of a product version with multiple "hosting" products, e.g. family concepts, is handled through the ProductView concept. So for a given ProductVersion, multiple ProductViews of the hosting product concepts would have hasPart associations linking back to the ProductVersion of note Q8: CLOSED at V1.0 What if a resource doesn’t support versioning, a resource factory for a ResourceVersion as a SHALL is over stating the need ?<br /><br />ANSWER: A creation factory service for a ResourceVersion is an optional MAY. Note that the version creation has an open issue below. Note: The Core extensions Spec has been updated.PM Spec draft not updated ACTION: Update PM Spec <strong><u>CLOSED Issues</u></strong> ISSUE 1. CLOSED at V1.1 Comments on clarity from Olivier Berger 17/11. http://open-services.net/pipermail/oslc-plm_open-services.net/2011-November/000066.html <u> *Items on hold* </u> ISSUE 6 Lyo examples need to be shown HOLD %BLUE% %ENDCOLOR%
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r5
<
r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r5 - 14 May 2012 - 15:26:41 -
GrayBachelor
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback