In reviewing the specification 3.0 for CM and the guidance for linking (also, v3.0), I see no content that talks about the ‘versioning’ or otherwise management of link information - specifically in “global configuration” situations.
Is the understanding/expectation that the link information would be captured as part of the baseline of the Subject resource?
Across variants/branches, those links could differ.
Please advise…would also covet the “book, chapter, and verse” of the spec where an answer is provided.
Thanks! I actually had read that prior to posting, but am needing help on not just how the links are created, but if they are captured as part of a baseline of the Subject resource. The primer isn’t clear on this.
Links are just RDF properties against a concept resource subject URI in the graph of a versioned resource. Supported Operations on Versioned Resources describes how to update a version resource. Typically you perform an HTTP GET, followed by an HTTP PUT with revised RDF content (such as new properties or links) and If-match=etag header. This is the standard RESTful way that OSLC leverages to update any type of resource. Servers might either create a new version with the revised content, or if they support mutable versioned resources, update the existing version resource with the revised content.
Some alternative methods ares described in Supported Operations on Versioned Resources in a Configuration Context. A client can perform a GET followed by PUT on a concept resource URI with a specified configuration context. Or a client can perform a POST to a component in the context of a stream. These methods are sometimes useful when all you know is the concept resource URI and a configuration context, and do not know the URI of a specific versioned resource.