In this informative appendix we offer advice to OSLC Technical Committees on modeling links and relationships between OSLC resources.
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:
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.
Relationships in OSLC resources are at their simplest an RDF property whose object is a URI. In some cases within one system, it is necessary to require a closed link, i.e. require the object of a link be of one or more specific resource types. In general, it is better to be open like the web and not place restrictions on the type of resource linked to. The property's purpose and name should clearly reflect the scenarios it is supporting. Since the usage of these relationship properties may exist for a long period of time, specification authors should use great care in determining these.
As resources evolve over time, and they adapt to different situations, different types will be exposed as targets to existing link types. Well behaved clients should gracefully handle resource types they don't expect when exercising links in resources. Specifications should allow links to be open ended (have any type, specifying Range any), and use text in the property description to suggest expected types, without being limiting. For example: “Change request affects a plan item. It is likely that the target resource will be an oslc_cm:ChangeRequest but that is not necessarily the case.” Some implementations may only work well if the link object comes from a set of “known” or “expected” types. The following graceful degradation sequence is suggested for providers when an unexpected type is encountered:
There are also some anti-patterns that clients and servers should avoid.
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.