[oslc-core] Versioning and URI design

[Arthur Ryman]

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 <ian.green at uk.ibm.com>
To:
oslc-core at open-services.net
Date:
03/15/2010 07:20 AM
Subject:
[oslc-core] Versioning and URI design
Sent by:
oslc-core-bounces at open-services.net



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

ian.green at uk.ibm.com (Ian Green1/UK/IBM at 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
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net