Resolving IRIs and Content Negotiation

In the core xAPI specification, IRIs may be used simply as identifiers without ever being resolved or dereferenced. However, following LD principles, vocabulary datasets and vocabulary term IRIs must be resolvable using the HTTP protocol. The primary reason for making vocabulary IRIs resolvable is to provide a reliable mechanism to obtain the actual meaning of the vocabulary terms, readable by humans or machines. Applications can use a variety of methods to generally read data, but resolving IRIs is the most common mechanism for LD. The terms "resolving" and "dereferencing" an IRI are often used interchangeably. Technically, IRI resolution is the process of determining an access mechanism and the appropriate parameters (e.g., Accept request headers in HTTP and media type). To use that access mechanism to perform an action on the IRI's resource is to “dereference” the IRI” (Baskauf, 2014). This formal definition comes from RFC3986. IRI resolution may require several iterations and is often achieved through an HTTP mechanism called content negotiation.

Content negotiation is defined in the formal HTTP specification and makes it possible to serve different representations of data at the same IRI, so that user agents can resolve which representations fit their needs the best. Different client applications might have different preferences on the data format, which is indicated in the HTTP header of the request.

As previously stated non-information resources such as real-world physical objects or abstract concepts can not be transmitted electronically. Instead, the server responds to a client requesting the IRI with the HTTP response code “303, See Other,” and the corresponding URL of a web document. This is called a 303 server-side redirect. Next, the client accepts this new target URL and retrieves a document describing the resource. For example, when accessing an xAPI vocabulary IRI (e.g., a browser usually requests HTML to provide a human readable version while other applications looking for semantic meaning will request RDF formats such as JSON-LD. The server hosting these files selects the best match based on the request and sends the file back to the client. For example, consider the following IRIs:

  • (IRI identifying the ADL Vocabulary Dataset & HTML document describing the vocabulary)
  • (IRI identifying the “abandoned” verb)

Accessing the ADL Vocabulary ( IRI in a browser will only provide a human-readable HTML representation of the dataset, but executing a HTTP GET request (e.g., curl --header "Accept: application/ld+json" -L of this IRI will return a response in JSON-LD. Each Verb IRI will also return the vocabulary dataset as HTML or JSON-LD through content negotiation. Content negotiation is managed on a web server and often requires administrative privileges and specialized knowledge of HTTP redirect rules. Vocabulary authors, who do not follow IRI persistence practices by leveraging a dedicated service for managing IRIs, will need to own, configure, and maintain their own server for content negotiation. Fortunately, vocabulary authors whocreate IRIs using W3C’s Permanent Identifier Service,, do not have to be concerned with content negotiation as that server is already configured to handle it. Vocabulary authors can simply generate a text-based .htaccess file and specify the target server’s URL from which the negotiated files will be delivered. An .htaccess code example that uses the W3C’s Apache server is available in Appendix B.

Editor’s Note: The original ADL vocabulary IRI ( was published before vocabulary practices were researched and established. Therefore, the original ADL vocabulary is still preserved, but for this documentation is also mirrored at to illustrate good IRI practices. When using the original ADL verbs for identifiers in actual xAPI statements, developers and CoPs should continue to use the original IRI path at Newly "minted" ADL vocabulary terms (e.g., cmi5 verbs) will use a persistent IRI (e.g., so that IRIs can be better designed and maintained using the W3C's permanent identifier process.

results matching ""

    No results matching ""