What do the resources inside a ServiceProvider look like?

Any HTTP resource with any representation might be found inside a ServiceProvider. In many of the most interesting cases, the resources will be OSLC resources. An OSLC resource is simply a resource whose type is defined in some OSLC specification, usually one of the domain specifications created by one of the OSLC domain workgroups. All OSLC resources share some common characteristics.

1. You can request an RDF/XML representation of the resource. All OSLC resources have their state defined by a set of RDF properties that may be required or optional. This set of properties was designed to support OSLC integration scenarios – it is expected that any particular resource may have many more properties that are not defined in an OSLC specification. The ability of RDF to represent this kind of open extensible information model is one of the reasons it was chosen for OSLC.
2. Although an OSLC resource’s state must be expressible in RDF, and it must have an RDF/XML representation, the resource may have other representations as well. You have already seen examples of Turtle - HTML and JSON would be popular additions, and OSLC sets no limits.
3. OSLC protocols use standard media types. OSLC does not require and does not encourage the definition of any new media types. The goal is that any standards-based RDF or Linked Data client be able to read and write OSLC data, and defining new media types would prevent that in most cases.
4. OSLC resources use common property names for common concepts. In the current state of the art in lifecycle tools, each tool defines its own properties for common concepts like label, description, creator, last-modification-time, priority, and so on. In many cases an administrator can define these properties locally for an installation, so the tool vendors may not control the vocabulary. This is usually viewed as a good feature by practitioners who want their tools to match their local terminology and processes, but it makes it much harder for organizations to subsequently integrate tools in an end-to-end lifecycle. OSLC resolves this by requiring all tools to expose these common concepts using a common vocabulary for properties, which you will remember are identified by URIs in RDF. Tools may choose to additionally expose the same values under their own private property names in the same resources. In general, OSLC avoids inventing its own property names where possible – it uses ones from popular RDF-based standards like the RDF standards themselves, Dublin Core, and so on. In some cases, OSLC has invented property URLs where no match was found in popular standard vocabularies.

RDF classes and properties in OSLC

OSLC resource types can be used as the value of the rdf:type predicate in resources. Following the standard rules of RDF, this means that OSLC resource types are RDFS classes (by definition of rdf:type in the RDF spec).

A resource’s membership in a class extent can be indicated explicitly – by a triple in the resource representation that uses the rdf:type predicate and the URL of the class - or derived implicitly. In RDF and OSLC there is no requirement to place an rdf:type triple in each resource, but this is a good practice, since it makes query more useful in some cases.

OSLC Datatypes

OSLC uses RDF concepts to define a number of standard properties. OSLC properties are RDF properties (by definition, because they are used as predicates). RDF does not by itself define datatypes to be used for property values, so OSLC lists a set of standard datatypes to be used in OSLC. The list is Boolean, DateTime, Decimal, Double, Float, Integer, String and XMLLiteral. Of course, OSLC also uses URI references and blank nodes as described in the RDF documentation.

The intention of some OSLC properties – like oslc:service, oslc:creationFactory and oslc:queryCapability – is that they only be used to reference blank nodes, never to reference true HTTP resources. To be able to express this intent, the OSLC Core specifies a number of OSLC-specific value types that are used in the specification and can also be found in ResourceShape (see later) property descriptions. These are the “resource value types”, Resource, Local Resource, and AnyResource. Resource means that the value will be an RDF URI reference. Local Resource means the value will be an RDF blank node identifier and AnyResource means it can be either. The OSLC specification allows you to further specify whether the referenced resource must be defined inside the same representation that contains the reference, in a separate document, or either, using the following values for the representation property of the property: http://open-service.net/ns/core#Reference, http://open-service.net/ns/core#Inline, or http://open-service.net/ns/core#Either

Unknown properties and content

As described before, OSLC depends on an open model for resource state. The specification defines some standard properties for integration, but also assumes that any given resource may have many more properties than are defined in the specification. Some tools will only support a fixed set of properties for a particular type of resource and may provide a ResourceShape that lists that set of properties. Clients should still assume that the set of properties for a type in an arbitrary tool may be open. This can happen several different ways. One is that the tool specifically supports an extensible set of properties in the sense that different resources of the same type may not all have the same properties. Another possibility is that the list of properties is fixed at any one time, but that older or newer resources may have different properties.

For OSLC Defined Resources, clients should assume that an OSLC server implementation may discard triples for properties of which it does not have prior knowledge - an OSLC implementation may discard property values that are not part of the resource definition or Resource Shape known by the server.

The rule is different for clients. When doing an update, OSLC clients must preserve any unknown property-values and other content in OSLC Defined Resources.

Open Model

Many specifications have a “closed model”, by which we mean that any reference from a resource in the specification will necessarily identify a resource in the same specification or a referenced specification. UML is an example of a closed specification – every UML reference is to another UML object. By contrast, the HTML anchor tag can point to any HTTP resource, not just other HTML resources. OSLC works more like HTML in this sense. Here are some examples:

1. Any HTTP resource can be contained in a ServiceProvider, not just resources defined in OSLC specifications.
2. A URL reference in one OSLC resource may in general point to any HTTP resource, not just an OSLC resource. OSLC specifications will not usually constrain the value for a property in one OSLC specification to be the URL of a resource in a different OSLC specification (footnote 3), although it is common for a property defined in one OSLC specification to constrain its value to being the URI reference of a resource in the same specification.

OSLC specifications generally avoid constraining a reference to be a resource in another specification. This independence allows OSLC specifications to evolve independently, and new ones to be added, without changing existing ones, and also allows tools at different version levels to interoperate.

Optimistic Collision Detection on Update

Because the update process involves first getting a resource, modifying it and then later putting it back to the server there is the possibility of a conflict, e.g. some other client may have updated the resource since the GET. To mitigate this problem, OSLC implementations should use the HTTP If-Match header and etags to detect collisions.