HistoryViewLinks to this page 2012 September 7 | 02:54 pm

When an automated client gets a resource and examines its properties, perhaps the most important property is the resource type. The OSLC AM specification defines only two resources types; a generic resource type, and a link type. If the resource is a generic AM resource there isn’t much an automated client can assume about it, other than it is something that is part of the architecture domain, and that it is likely to have an identifier and title property. It can also have links (properties whose values reference other resources). Clients navigating links should be prepared to expect any type of resource on the other end of a link.

When a client GETs a resource it can look at its rdf:type property to determine what type(s) it is. Based on the type it might do something interesting (like continue to follow links or not).

One problem is there are no standard sets of known rdf:type URIs to describe common architecture resource types. One implementation provider may use http://acme.com/types/usecase while another may use http://eclipse.org/uml#usecase and so on.

An automated client may not want or need to know the details about the shape (other than it is a valid AM resource with a title, identifier and links). But just knowing that the resource is an architecture type that it knows exists (i.e. use case, service operation, database table) it can decide to do something interesting with it.

What we are proposing here is that for common architecture resource types (and link types) we provide an OSLC originating URI that service providers can use. This proposal stops short of also saying that the given type URIs also have a defined shape (that is for another discussion). This is just about defining URIs that map to common architectural resources and concepts so that service implementations don’t have to invent a type URI in their own domain, that only clients coded for that implementation would understand.

When the standard URI exists we use it, and no definition in the open-services.net space is required. We just add it to our published list as a courtesy.

The following is an example of the kinds of types we are talking about.

Common Architecture Resource Types

Name Description URI External Reference
UML Class A UML Class http://open-services/ns/am/uml#class http://www.omg.org/spec/UML/2.3/
Use Case A UML style use case that represents the description of behavior of a system (without specifying how) in response to external stimuli. http://open-services/ns/am/uml#usecase http://www.omg.org/spec/UML/2.3/
Table A relational database table. http://open-services/ns/am/sql#table ISO/IEC 9075-11:2008