[oslc-plm] [oslc-core] Updated Core extension proposal forversioning

[michael.loeffler at gm.com]

Reposting with non-HTML formatting, sorry for the duplication...

Hi John, 

Thanks for your comments, I've put some some answers and feedback
inline below, let's keep this discussion rolling until we get it 
nailed down... 

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

I'm not an RDF expert, never thought of this approach myself but it 
seems to make good sense to me. The XML tags and the rdf:type do seem 
a bit redundant in our current proposal. If this approach makes the 
backward compatibility work better then I think it warrants careful 
consideration. I will attempt to modify my test data generator to this
approach and post some results to the wiki in support of further 
discussion. I am looking into the Lyo reference implementation now, it 
seems that the XmlFormatter assumes that the type and the resource node
name must match, so there could be some minor issues but we'll see.

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

I think the right approach is to throw an error if the resource has 
<rdf:type rdf:resource="http://open-services.net/ns/core#Version"> but 
no dcterms:isVersionOf triple. If the resource is really the base 
resource it should have the correct dcterms:type value and no 
dcterms:isVersionOf properties. 

If the client is unaware of versions it could just ignore the 
<rdf:type rdf:resource="http://open-services.net/ns/core#Version"/> 
and fall back to the right behavior based on the XML tag type. It might
be pretty ugly but it should be usable, each base and version is just 
a unique resource instance. 


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

Good point, I never thought of that issue. I think if we accept your 
revised approach above then this gets simpler, it becomes "resource 
with same Resource Prefixed Name" or equivalent. 


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

The "revise" behavior will be more thoroughly explained on the wiki. 

---
Mike Loeffler - GPD Systems Engineering IT 
GM IT Innovation Team 

Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. 

Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material.  Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.