In this informative appendix we offer advice to OSLC Technical Committees on modeling links and relationships between OSLC resources.


Relationships in OSLC

The Core workgroup's guidance to OSLC domain workgroups is that relationships are uni-directional and in most cases relationships should be modeled as links. We offer two ways to express relationships, a link and an anchor. Let's define those terms and others that we will use in this document:

  1. Relationship: a relationship is said to exist between two resources if there is something that connects them; they work together, belong together, are similar or should be considered together. There may be different types of relationships.
  2. Link: a link is a URI reference from one resource, the subject or source, to another resource, said to be the object or target. In RDF and in OSLC we use links to model relationships and like relationships, links are uni-directional.
  3. Anchor: an anchor is a mechanism for attaching property-values to a link, thus annotating a relationship with values that are about that relationship.
Now that we've defined our terminology, let's move on to expressing relationships.

Expressing relationships for OSLC

The RDF data model gives us a number of value-types to express relationships, some more complex than others. We expect that the majority of links will be expressed with the most simple option, URI Reference or as it is known in conversation, a Link. In this simple case, a Link refers to a RDF assertion where the predicate is the URI. It is the subject, predicate, object that represents the relationship. For more complex cases, when a relationship must be annotated with property-values, we use what is called an Anchor, which is a link plus information that annotates or labels that link. Read the sub-sections below for details and examples of Links and Anchors.

Anchor

Anti-patterns

There are also some anti-patterns that clients and servers should avoid.

Use of Blank Nodes

Blank nodes may be a convenient shorthand to use in examples - especially in Turtle where the [ ... ] syntax makes blank nodes easy to use. However, blank nodes may make queries and updates much harder, since there is no way to reference a specific blank node later. Introducing an explicit resource with its own URI is usually better practice.

Below is an example of a Blog Entry resource with a blank node for an uploaded-file resource.

@prefix dcterms:  <http://purl.org/dc/terms/> .
@prefix blog:     <http://open-services.net/ns/bogus/blog#> .

<http://example.com/blogs/entry/5>
  a blog:BlogEntry ;
  dcterms:title "New Wink release available" ;
  blog:attachment [
    a blog:UploadedFile ;
    dcterms:title "wink-0.9.6.jar"
  ] .

It would be better to represent the uploaded-file resource with an explicit URI. Note that having an explicit URI does not mean the resource has to be sent in a different HTTP request; in this example, we use a hash URI to have the uploaded-file resource returned in the same HTTP request as its parent blog entry resource.

@prefix dcterms:  <http://purl.org/dc/terms/> .
@prefix blog:     <http://open-services.net/ns/bogus/blog#> .

<http://example.com/blogs/entry/5>
  a blog:BlogEntry ;
  dcterms:title "New Wink release available" ;
  blog:attachment <#file> .

<#file>
  a blog:UploadedFile ;
  dcterms:title "wink-0.9.6.jar" .

Feedback should be directed to the OSLC Core Workgroup mailing-list. TBD - put link here.