[oslc-core] Updated Core extension proposal for versioning

[John Arwe]

I find this fairly hard to parse.  Keeping conflicting information 
interleaved in the same document makes it very vulnerable to unintended 
readings.  (Example: It shall support ... NOTE: ...shall not be ... . 
Proposed to rescind this as per the Q&A below at 11/11 ")

Comment 1:
> Versions of a base resource have a type of Resource Version 
I think I understand the intent.  I know I don't like what this does to 
the type space (doubles its size for anything versioned).  It also brings 
up a spec authoring problem similar to what I asked about reverse links - 
since the "ResourceVersion" types must be defined, "adding" version 
capability to an already-defined resource (like those in AM) requires 
opening up the AM spec; new specs either have to add "ResourceVersion" 
types speculatively (in advance of scenarios) to avoid the need to rev 
them later, or pay the time delay and adoption implication costs of 
revving the specs to add versioning afterward.  That seems fairly easily 
avoidable in RDF too -- define a single Version resource pretty much as 
you have it, and just compose it into any versioned instances regardless 
of their type.   Using the second resource [2] in your Examples table [1], 
the changes would be:
1 - <oslc_am:ResourceVersion rdf:about="
http://localhost:8080/tcua-oslc/resourceversion/Tm_ZkV3LQyYmUC">  ... 
becomes oslc_am:Resource, same as the base
2 - <rdf:type rdf:resource="http://open-services.net/ns/am#ResourceVersion
"/> ... becomes .../core#Version  (the /am#Resource rdf type is implied by 
the oslc_am:Resource parent element in this XML example, it could also be 
rendered explicit without harm).
Clients aware of Versions can test for <rdf:type rdf:resource="
http://open-services.net/ns/core#Version"/> to know if a resource instance 
is asserted to be a Version or not.  If a Version, client expects to find 
>=1 dcterms:isVersionOf triple; if not (presumably - would need your 
feedback here) such a client would assume a resource instance is a Base, 
and inspect it for the optional dcterms:hasVersion triple(s).  Such a 
client would have the option of limiting itself to that "view of the 
world" or it could also choose to provide additional behavior based on 
other content it finds (like rdf:type values).  That seems pretty generic, 
so the client code would be able to process a wide breadth of resource 
types w/o being sensitive to each most derived type.
Clients unaware of Versions simply ignore the content like any other they 
don't understand.
If we end up accepting the  "ResourceVersion" types approach, I think 
you'd have to add a constraint too that "ResourceVersion" types must have 
identical required properties as the "Resource" type prior to "adding on" 
the ...Version resource definition's required properties.

Comment 2:
When you say "resource of same type" in your resource definition, what do 
you mean in RDF terms by that, remembering that an RDF resource has 
multiple types?

Comment 3: 
> It shall support a createVersion service
How would a client distinguish between the base resource's "legacy" 
creation factory and this new one, given that oslc:Service only allows the 
oslc:domain URI as a way to distinguish them?  It appears that you'd need 
each spec to define a URI for its createVersion service when it wants to 
support versioning.  A single creation factory may accept many different 
input representations on create, including those with different types, so 
it's not obvious to me why you want to require a separate factory ... if 
the need is accepted, then I don't see how you avoid the need for another 
URI in each "version supporting" spec (and is it 1 URI/spec, or 1/resource 
definiton?).

Comment 4: 
When you say rdf:type occurs zero-or-many in your resource definition, I 
think you want one-or-many given your requirement that >=1 be the type URI 
for ResourceVersion.



[1] 
http://open-services.net/bin/view/Main/CoreExtensionForPlm?sortcol=table;up=#Appendix_A_Samples
[2] 
http://open-services.net/pub/Main/CoreExtensionForPlm/AM_versioned_resource_examples_AMG60104_004-POWERSUBSYSTEM.xml

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario




From:   Gray Bachelor <gray_bachelor at uk.ibm.com>
To:     oslc-plm at open-services.net, oslc-core at open-services.net
Date:   11/10/2011 09:15 PM
Subject:        [oslc-core] Updated Core extension proposal for versioning
Sent by:        oslc-core-bounces at open-services.net



Dear OSLC PLM and Core workgroup members 

Following the Oct 5th meeting and postponed Core Nov 2nd 

please find update Core proposal for versioning support with examples 

Some of the feedback has been included 

http://open-services.net/bin/view/Main/CoreExtensionForPlm 

I cant make the Core WG 16th so I look forward to your feedback 

Suggestions are welcomes to build up the wiki page

Best regards
Gray

Solution Architect
Systems and Industrial solutions, Rational HQ Devt org, IBM SWG
Tel: (44)(0)1926-464345      Alternative Tel: (44)(0)2476 713 274  Mobile 
Tel: (44)(0)784 10 11 431
E-mail   gray_bachelor at uk.ibm.com




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 





_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111123/a8d7a98b/attachment-0003.html>