-->

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This specification is published under the Attribution 4.0 International (CC BY 4.0). Portions of this specification are also provided under the Apache License 2.0.

All contributions made to this project have been made under the OASIS Contributor License Agreement (CLA).

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Open Project or OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.


Table of Contents


1. 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.

2. Expressing relationships for OSLC

This section is non-normative.

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.

2.2 Anchor

2.3 Anti-patterns

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

2.3.1 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.

Example 7: Blog Entry with blank node for file
@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.

Example 8: Blog Entry with hash URI for file
@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.


Appendix A. References

A.1 Informative references

[OSLCCore3]
Jim Amsden; Andrii Berezovskyi. OSLC Core Version 3.0. Part 1: Overview. OASIS. OASIS Standard. URL: https://open-services.net/spec/core/latest