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 intent of a special createVersion service was to support the typical behavior of "revising" an existing resource, but that can probably be handled just as easily by rules on the behavior of the existing resource creation factory. If the resource provider supports versioning, it should interpret a POST of an existing resource as a request to create e new version of that resource, whether the input resource is a base or an existing version. If the POST contains a new resource it just creates the base and first version, returning the version. A PUT to an existing resource (base or version) acts the same as now, changing the content of that resource itself, and setting the modification properties accordingly. It is important to note that version resources are not expected to be immutable unless they have been "locked" from further edits by an approval or locking of some fashion. These locking semantics are still to be proposed and clarified, but the concept exists in all PLM systems so it is not a new idea. I think this will be complementary to the "baseline" idea; a "baseline" will be a version that has been locked but not specifically "approved" for any other purpose. "Approved" would perform the same as "baseline" but with some added information describing the approval intent.
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.
