Ian, I think the one thing that OSLC should do it clarify what we mean by format versions. There are a couple of ways to look at this:
1. Different versions of a format define different representations for a resource, e.g. V1 is proprietary RDF/XML and V2 is OSLC RDF/XML In this view, the resource has one URL so we'd need to specify the desired format version in the HTTP GET request, e.g. via a custom content type for each version. Although this is tempting, the profusion of content types would be hard to manage. Furthermore, this approach is not semantic Web friendly since we don't have URIs for the alternate versions. 2. Different versions of a format define alternate information resources that describe a given real-world object or thing. The semantic Web promotes the notion that there is a difference between real-world objects (aka things) and information resources that describe them. [1] Real-world objects include abstract concepts (e.g. Requirements). Information resources are things that exist in computers. URIs are used to identify both, but for information resources, the URIs also locate the information. If you dereference a real-world HTTP URI, the server should redirect you to an information resource about it. I think approach #2 is the right one for OSLC. Given this approach, we'd want to represent the fact that V1 and V2 formats describe the same resource. One way to do this is to denote a common OSLC property, e.g. oslc:thing, that identifies the real-world object that an information resource described. We could also define version-specific properties that pointed to earlier versions of the information resource, e.g. rm:seeAlsoV1 would be included in a V2 RM information resource. [1] http://www.w3.org/TR/cooluris/#semweb Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube From: Ian Green1 <[email protected]> To: [email protected] Date: 03/15/2010 07:20 AM Subject: [oslc-core] Versioning and URI design Sent by: [email protected] Hello all, What guidance, if any, should OSLC offer to implementers of OSLC specifications around versioning of services and design of URIs? Here are a couple of example scenarios: Scenario A: Provider has a product with web clients, public REST APIs. These resource models offer application/rdf+xml representations of resources, but these representations differ from the OSLC representations. Provider wants to additionally offer OSLC protocols & representations. One approach is to have OSLC-specific URIs. Is anyone aware of scenarios where consumers would need to consume both OSLC and non-OSLC services over the same resources? Scenario B: Provider offers OSLC services at v1 of an OSLC specification. Provider wants to additionally offer OSLC v2 services. (Let's assume that v2 is not backwards compatible with v1.) Provider has quality of service contracts which prevent it from withdrawing OSLC v1 services. Provider has consumers which cannot upgrade to v2 services. Provider has prospective consumers who cannot downgrade to v1 services. One possibility is that v1 resources and v2 resources differ in their URIs. (This scenario differs from A because A is less constrained.) This would have ramifications for consumers that pass URIs between providers (for example, C/ALM filters might break). URI stability is crucial and I wonder if we ought to give some help to providers on how that can be achieved, what concerns need to be considered, what can be done if URIs "must" change and so on. best wishes, -ian [email protected] (Ian Green1/UK/IBM@IBMGB) Chief Software Architect, Requirements Definition and Management IBM Rational 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 [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
