http-behavior.md

http-behavior.md

RightsStatements.org: Dereferenceability discussion paper

• Author: Mark A. Matienzo, Digital Public Library of America
• To: Technical Group of International Rights Statement Working Group
• CC: International Rights Statement Working Group
• Status: Personal views only
• View link: http://bit.ly/rs-http-behavior
• Public comment link: https://gist.github.com/anarchivist/16140cfa8c76008e384e

Notes and definitions

• For the sake of brevity, the shorthand http://rs.int/ is used for the full URI base http://rightsstatements.org/.
• This document, when rendered properly, contains diagrams to represent HTTP interactions. If you do not see the diagrams, please use the view link provided.
• A rights statement URI is defined as the URI uniquely identifying the rights statement included in the SKOS concept scheme [RSSKOS] under development by the Technical Working Group.
• A human-readable representation is understood to refer to a representation to be presented to a person, e.g. an HTML page rendered in a web browser.
  • A human-readable representation MAY have additional metadata passed to it as a "payload."
  • A human-readable representation MAY also have a translation of the statement into a non-English language. Such a translation MUST be derived from a set of assertions with appropriate language tags in the canonical SKOS version [RSSKOS] of the rights statements.
• A representation URI is defined as the URI uniquely identifying a derived representation of a given rights statement.
  • A machine-readable representation URI is understood to refer to a representation understood to be processed by an automated client.
  • A human-readable representation URI is understood to refer to a representation to a human-readable representation.

Background

This discussion originates in work from a joint DPLA/Europeana Rights Statements Working Group. For more background please read the Working Group's draft white papers on recommended statements [RSRECS] and technical infrastructure [RSTECH].

In the white paper on technical infrastructure [RSTECH], the proposed flow of HTTP requests follows the recommendations of Recipe 5, "Extended configuration for a 'slash namespace', using multiple HTML documents", of the Best Practice Recipes for Publishing RDF Vocabularies [SWBP-VOCAB-PUB], with an extension to support translations of rights statements. This memorandum addresses two needs identified during the discussion and revision process of the white paper on technical infrastructure [RSTECH]:

1. The need to add additional metadata "payloads" to human-readable representations of the rights statements. This is informed by needs around two specific statements as identified by Europeana.
   • The OOC-NC statement ("Out Of Copyright - NonCommercial Use Only") [RSTEXT] was created Public Domain works digitized in a public-private partnership. Within that partnership, the partners have agreed to limit commercial uses of this digital representation of the work by third parties. This statement needs an additional way to provide a contract expiry date that will allow the human-readable representation to the words until MM-DD-YYYY as part of the text displayed in the representation.
   • The InC-OW-EU statement ("In Copyright - EU Orphan Work") [RSTEXT] is designed for works identified as an orphan work in the country of first publication and in line with Directive 2012/28/EU [CELEX:32012L0028]. Since the beneficiary of the Directive is expected to have registered the work in the EU Orphan Works Database [EU-OW-DB], this statement needs an additional way to provide a link to the entry for the item in that database.
   • The proposed solution discussed by the technical working group suggested using a URI query parameter as part of the URI for the human-readable representation of rights statement, e.g.: http://rs.int/page/OOC-NC/1.0/?date=2028-01-01
2. The need to refer to individual translations of a rights statements if desired. The proposed behavior in the white paper on technical infrastructure [RSTECH] describes a dereferencing behavior for translations based upon the transmission of an Accept-Language header in the originating HTTP request. This makes it difficult to consistently refer the human-readable representation in linking from public user interfaces.

There was an initial proposal to use a implementation similar to that of the Creative Commons Metadata Scraper [CC-SCRAPER], which parses RDFa in HTML [HTML-RDFA] of a page identified using the Referer HTTP header [RFC7231] and creates a JSON response injected into deed pages.

Problem statement

The needs above and the proposed solutions raise the following issues:

1. The rights statement URI and the representation URI do not identify the same thing. Adopters (meaning either aggregators or their content partners) expressing the rights statements in their metadata need a mechanism to consistently refer to the same rights statement of a given version, following best practices and standards of web architecture [RDF11-CONCEPTS, COOLURIS, WEBARCH].
2. Specific guidance to adopters should be given about how to link to the appropriate resource if a specific human readable representation is desired. Without adequate guidance, this could lead to the confusion for adopters to associate the representation URI (e.g., one containing query parameters) to incorrectly as the rights statement URI.
3. Both human and machine clients need an easy way to make requests that include additional information, such as desired content language or additional metadata for the specific rights statements listed above. There is a strong desire to be able to dereference a URI to retrieve a representation containing requested data. The Technical Working Group discussed issues with the CC Metadata Scraper [CC-SCRAPER], which range from performance to concerns to a lack of robustness when working in both HTTP and HTTPS environments.
4. Both human and machine clients need adequate guidance to additional associated resources. The server hosting the statements needs to provide a reasonable set of behaviors that guide both kinds of clients to the appropriate resources. This is particularly true when links are used incorrectly, e.g. when a representation URI is used in place of the rights statement URI.

Proposed recommendations

Rights statement URIs should be different from representation URIs

Fundamentally, this is a restatement of the recommendations in Best Practice Recipes for Publishing RDF Vocabularies [SWBP-VOCAB-PUB], and was identified as a recommendation by a commentator on the technical infrastructure white paper [RSTECH].

• Rights statement URIs should start with a specific prefix, e.g. /vocab/ or/id/:

http://rs.int/vocab/ic/1.0

• Machine-readable representation URIs should start with a different specific prefix, e.g. /data/:

http://rs.int/data/ic/1.0

• Human-readable representation URIs should start with a different distinct prefix, e.g. /page/:

http://rs.int/page/ic/1.0

Adopters should use rights statement URIs and representation URIs differently depending on needs and context

• When an adopter uses the URI in metadata (e.g. in a set of RDF statements about an item), the URI associated with the rights statement should be the rights statement URI, e.g.:

http://rs.int/vocab/OOC-NC/1.0

• Additional data for certain statements (i.e. OOC-NC and IC-OW-EU) should be expressed in item metadata whenever possible (e.g. by using additional RDF statements).
• Links to the human-readable representation URIs can be created dynamically, or stored separately, either for human or API consumption. For example, an aggregator can link to the following example URI for an OOC-NC statement with an expiration date in the Spanish version of their site:

http://rs.int/page/OOC-NC/1.0/es?&date=2028-01-01

• Full example to demonstrate how both additional statements in RDF metadata can express this additional information, along with a link to a human-readable representation:

<http://ex.org/providedCHO1234> <:rights> [
  odrl:inheritFrom <http://rs.int/vocab/OOC-NC/1.0> ;
  cc:deprecatedOn '2022-01-01' ;
  ex:representation <http://rs.int/page/OOC-NC/1.0/?date=2028-01-01> .
] 

Responses to HTTP requests should provide additional guidance in headers about how to retrieve the proper resource depending on context

HTTP headers can provide appropriate guidance about how to access related resources. For example, headers returned when a client requests the representation URI can help them discover the associated rights statement URI.

Invalid requests

When a client makes an invalid request, e.g. when requesting an RDF representation of a rights statement with an additional metadata payload, the server should respond accordingly. This is in part by design to ensure that the rights statement URIs are applied appropriately. The proposed response in this context is to return a response with an HTTP 406 Not Acceptable [RFC7231] status for invalid requests.

> GET http://rs.int/vocab/OOC-NC/1.0?date=2028-01-01
---
< 406 Not Acceptable

The Alternates header

If a client requests a rights statement URI with query parameters containing an additional metadata payload, an Alternates header [RFC2295, RFC2296] can be returned with an HTTP 406 Not Acceptable [RFC7231] status. The Alternates header in this context functions as a means to provide guidance to a client when an unsuitable representation is requested.

> GET http://rs.int/vocab/OOC-NC/1.0?date=2028-01-01
---
< 406 Not Acceptable
< Alternates: {"/page/OOC-NC/1.0?date=2028-01-01" 0.9 {type text/html}}, {"/vocab/OOC-NC/1.0" 0.9}

The Content-Location header

The Content-Location header [RFC7231] is recommended to allow a generic machine-readable representation URI to refer to a specific machine-readable representation's URI, e.g.

> GET http://rs.int/data/ic/1.0
> Accept: text/turtle
---
< 200 OK
< Content-Location: http://rs.int/data/ic/1.0.ttl

The Link header

The Link header [RFC5988] is recommended to provide additional link relations [LINK-RELATIONS] between representation URIs and rights statement URIs.

The describedby link relation

The describedby relation [LDP-LINK-RELATIONS] returned in a Link header for a request for a rights statement URI can assert that it is described by the associated readable representation URI, e.g.

> GET http://rs.int/vocab/und/1.0/
---
< 200 OK
< Link: <http://rs.int/page/und/1.0/>; rel=describedby

The derivedfrom link relation

The derivedfrom relation [DRAFT-HOFFMAN-XML2RFC-21] in a Link header for a request for a representation URI can assert that the specified representation is derived from another representation. This may be useful to associate representations that are translations or have a specific metadata "payload."

> GET http://rs.int/page/OOC-NC/1.0/?date=2028-01-01
---
< 200 OK
< Link: <http://rs.int/page/OOC-NC/1.0/>; rel=derivedfrom

Detailed HTTP Interaction examples

The following represents the proposed interactions between a client and the server hosting the rights statements and their representations.

Dereference the vocabulary URI, requesting HTML content in a specific language

This is as a revised interaction pattern from that included in the working group's technical white paper [RSTECH].

Note left of Client: req1:\n \nGET http://rightsstatements.org/vocab/1.0/\nAccept: text/html\nAccept-Language: es
Client->Server: req1
Note right of Server: rsp1:\n \n303 See Other\nLocation: http://rightsstatements.org/page/1.0/?language=es
Server-->Client: rsp1
Note left of Client: req2:\n \nGET http://rightsstatements.org/page/1.0/?language=es\nAccept: text/html\nAccept-Language: es
Client-Server: req2
Note right of Server: rsp2:\n \n200 OK\nContent-Language: es\nLink: <http://rs.int/page/1.0/>; rel=derivedfrom
Server-->Client: rsp2

Dereference the URI of a rights statement, requesting HTML content in a specific language

This is as a revised interaction pattern from that included in the working group's technical white paper [RSTECH].

Note left of Client: req1:\n \nGET http://rightstatements.org/vocab/InC/1.0/\nAccept: text/html\nAccept-Language: es
Client->Server: req1
Note right of Server: rsp1:\n \n303 See Other\nLocation: http://rightstatements.org/page/InC/1.0/?language=es
Server-->Client: rsp1
Note left of Client: req2:\n \nGET http://rightstatements.org/page/InC/1.0/?language=es\nAccept: text/html\nAccept-Language: es
Client-Server: req2
Note right of Server: rsp2:\n \n200 OK\nContent-Language: es\nLink: <http://rightstatements.org/page/InC/1.0/>; rel=derivedfrom
Server-->Client: rsp2

Dereference the URI of a rights statement, requesting RDF content

Note left of Client: req1:\n \nGET http://rightstatements.org/vocab/InC/1.0/\nAccept: text/turtle
Client->Server: req1
Note right of Server: rsp1:\n \n303 See Other\nLocation: http://rightstatements.org/data/InC/1.0/
Server-->Client: rsp1
Note left of Client: req2:\n \nGET http://rightstatements.org/data/InC/1.0/\nAccept: text/turtle
Client-Server: req2
Note right of Server: rsp2:\n \n200 OK\nContent-Type: text/turtle\nContent-Location: http://rightstatements.org/data/InC/1.0.ttl\nLink: <http://rightstatements.org/page/InC/1.0/>; rel=derivedfrom
Server-->Client: rsp2

Dereference a OOC-NC statement with expiration date by the representation URI

Note left of Client: req1:\n \nGET http://rightstatements.org/page/OOC-NC/1.0/?date=2028-01-01
Client->Server: req1
Note right of Server: rsp1:\n \n200 OK\nLink: <http://rightstatements.org/page/OOC-NC/1.0/>;\n  rel=derivedfrom\nContent-Type: text/html; charset=utf-8\n \n<!DOCTYPE html>\n\n<!-- skip -->\n...This expires on 01 January 2028 ...
Server-->Client: rsp1

Dereference a OOC-NC statement with expiration date by the statement URI, requesting HTML

Note left of Client: req1:\n \nGET http://rightstatements.org/vocab/OOC-NC/1.0/?date=2028-01-01\nAccept: text/html
Client->Server: req1
Note right of Server: rsp1:\n \n406 Not Acceptable\nAlternates: {"/page/OOC-NC/1.0/?date=2028-01-01" 0.9 {type text/html}},\n{"/vocab/OOC-NC/1.0/" 0.9}
Server-->Client: rsp1
Note left of Client: req2:\n \nGET http://rightstatements.org/page/OOC-NC/1.0/?date=2028-01-01
Client-Server: req2
Note right of Server: rsp2:\n \n200 OK\nLink: <http://rightstatements.org/page/OOC-NC/1.0/>; rel=derivedfrom\nContent-Type: text/html; charset=utf-8\n \n<!DOCTYPE html>\n\n<!-- skip -->\n...This expires on 01 January 2028 ...
Server-->Client: rsp2

Dereference a OOC-NC statement with expiration date by the statement URI, requesting RDF

Note left of Client: req1:\n \nGET http://rightstatements.org/vocab/OOC-NC/1.0/?date=2028-01-01\nAccept: text/turtle
Client->Server: req1
Note right of Server: rsp1:\n \n406 Not Acceptable\nAlternates: {"/page/OOC-NC/1.0/?date=2028-01-01" 0.9 {type text/html}},\n{"/data/OOC-NC/1.0/" 0.9 {type text/turtle}}
Server-->Client: rsp1
Note left of Client: req2:\n \nGET http://rightstatements.org/data/OOC-NC/1.0/\nAccept: text/turtle
Client->Server: req2
Note right of Server: rsp2:\n \n200 OK\nContent-Location: http://rightstatements.org/data/OOC-NC/1.0.ttl\nLink: <http://rightstatements.org/page/OOC-NC/1.0/>; rel=derivedfrom
Server-->Client: rsp2

Dereference an InC statement with an invalid parameter by the representation URI, requesting HTML

Note left of Client: req1:\n \nGET http://rightstatements.org/page/InC/1.0/?date=2028-01-01\nAccept: text/html
Client->Server: req1
Note right of Server: rsp1:\n \n406 Not Acceptable\nAlternates: {"/page/InC/1.0/" 0.9 {type text/html}},\n{"/data/InC/1.0/" 0.9 {type text/turtle}}
Server-->Client: rsp1
Note left of Client: req2:\n \nGET http://rightstatements.org/page/InC/1.0/\nAccept: text/html
Client->Server: req2
Note right of Server: rsp2:\n \n200 OK\nContent-Type: text/html
Server-->Client: rsp2

References

[CC-SCRAPER] Creative Commons. Deed Metadata Scraper.

[CELEX:32012L0028] European Parliament, Council of the European Union. Directive 2012/28/EU of the European Parliament and of the Council of 25 October 2012 on certain permitted uses of orphan works.

[COOLURIS] Leo Sauermann; Richard Cyganiak. Cool URIs for the Semantic Web. 3 December 2008. W3C Note.

[draft-hoffman-xml2rfc-21] P. Hoffman. The 'XML2RFC' version 3 Vocabulary. 6 July 2015. Internet-Draft.

[EU-OW-DB] Office for Harmonization in the Internal Market. Orphan Works Database.

[HTML-RDFA] Manu Sporny. HTML+RDFa 1.1 - Second Edition. 17 March 2015. W3C Recommendation.

[LINK-RELATIONS] Internet Assigned Numbers Authority. Link Relation Types.

[LDP-LINK-RELATIONS] Steve Speicher; John Arwe; Ashok Malhotra. "Link Relations." Linked Data Platform 1.0. 26 February 2015. W3C Recommendation.

[RDF11-CONCEPTS] Richard Cyganiak; David Wood; Markus Lanthaler. RDF 1.1 Concepts and Abstract Syntax. W3C Recommendation, 25 February 2014.

[RFC2295] K. Holtman; A. Mutz. Transparent Content Negotiation in HTTP. March 1998. Experimental.

[RFC2296] K. Holtman; A. Mutz. HTTP Remote Variant Selection Algorithm -- RVSA/1.0. March 1998. Experimental.

[RFC5988] M. Nottingham. Web Linking. October 2010. Proposed Standard.

[RFC6892] E. Wilde. The 'describes' Link Relation Type. March 2013. Informational.

[RFC7231] R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard.

[RSRECS] International Rights Statements Working Group. Recommendations for Standardized International Rights Statements. May 2015.

[RSSKOS] International Rights Statements Working Group. RightsStatements.org data model. 15 July 2015.

[RSTECH] International Rights Statements Working Group. Recommendations for the Technical Infrastructure for Standardized International Rights Statements. May 2015.

[RSTEXT] Europeana/DPLA working group: detailed list of rights statements. July 2015.

[SWBP-VOCAB-PUB] Diego Berrueta; Jon Phipps. Best Practice Recipes for Publishing RDF Vocabularies. 28 August 2008. W3C Note.

[WEBARCH] Ian Jacobs; Norman Walsh. Architecture of the World Wide Web, Volume One. 15 December 2004. W3C Recommendation.

See comments in #projecthydra IRC logs, e.g.

> 12:37 <barmintor> tjohnson: regardless of all the dcterms stuff, I think it is still pretty
clear that the date is not characteristic of the representation
> 12:40 <barmintor> tjohnson anarchivist in that case I think you just have to make
clear what you are hosting does not have context, and perhaps distinguish the things
you host on the basis of their variability

More IRC comments:

> 11:13 <cbeer> anarchivist: i think i'm struggling with derivedfrom, but still trying
to figure out a specific complaint. 
> 11:13 <cbeer> (and the pattern seems fine)
> 11:14 <anarchivist> cbeer: ok, thanks - feel free to comment later if something jumps out
> 11:16 <cbeer> anarchivist: i think one use case is "show me all X that are out of
copyright", and i'm not sure derivedfrom is strong enough to make that inference. 
> 11:20 <cbeer> anarchivist: i also wonder if Memento/TimeGate may have useful
HTTP interaction patterns (but i kinda doubt it, i suspect they get into the same
HTTP header trouble)

and

> 11:24 <terrellt> The problem I have is that the rights statement URI will NOT have
an expiration date associated with it, but the "representation" URI will.
> <anarchivist> terrellt: the "representation" URI *MAY* have additional metadata
expressed as part of it
> <anarchivist> and the idea is you have http://foo/page/bar?expirationDate=2028-01-01
display a page that has something like "The date of this contract's expiration is 1
January 2028"
> 11:27 <tjohnson> terrellt: is your concern that the `describes` relation is inaccurate
for http://rs.int/page/ooc-nc/0.0?expirationDate=2028-01=01 ?
> <terrellt> tjohnson: Yes
> <anarchivist> s/display a page/display a fragment on a page/
> <tjohnson> i think you have a point
> 11:28 <tjohnson> the `derivedfrom` is true, and is maybe good enough?
> <barmintor> anarchivist: I mean, I can imagine “IRSIF: a linkable API for referring to
rights statements”, but that rather pointedly is not query params, and lays out a different
goal than identification and geneaology

Other options: delegate the human-readable representation with additional metadata to partners who actually need it?

I've posted some commentary on this on the project Basecamp, but for anyone following along externally, my position is:

• This proposal handles the issue of an API for passing additional contextual information to rights display pages correctly.
• It's important to emphasize that those pages are not strictly representations of the dct:RightsStatements, but rather are derivatives that explain the statement with the added context as passed to the API; i.e. the API is not a framework for creating new rights statements.
• Users of the statements who have use cases (such as the expiration date example; but notably not the language examples) that alter the interpretation of the statement SHOULD express that programmatically; they have at least two options:

(1) create "derivative" statements, optionally with unique text as follows:

 <http://ex.org/providedCHO1234> edm:rights   
  [ a dct:RightsStatement ;     
    dct:source <http://rs.int/vocab/ooc-nc/0.0> ;     
    skos:prefLabel "A new statement derived from ooc-nc" ; ] 

Further properties could be added to this ad-hoc statement specifying its expiration, etc... in machine readable format.

(2) use a data model with a "rights policy" node:

<http://ex.org/providedCHO1234> :policy
  [ :rights <http://rs.int/vocab/ooc-nc/0.0> ;     
    :endDate '2022-01-01' ; ] 

:policy and :rights would need to be defined in a way that allowed inference of the triple <http://ex.org/providedCHO1234> edm:rights <http://rs.int/vocab/ooc-nc/0.0> until the specified date.

Lastly, I believe the use of rel=describes in the link headers for API requests that alter the interpretation of the statement (e.g. in the diagram for http://rs.int/page/ooc-nc/0.0?expirationDate=2028-01-01) are problematic. The rel=derivedfrom header seems appropriate and, for me, provides the correct context for the API pages.

EDIT:

A third option, which suffers from a lack of both formality & machine readability, but is easiest to implement is:

<http://ex.org/providedCHO1234> edm:rights <http://rs.int/vocab/ooc-nc/0.0> ;
   dce:rights "The rights restrictions for this item expire on [DATE]; after that date, the rights status is [STATUS]" .

Hi,

Two quick comments...

I'm not sure I get the need for alternate headers. We don't want the representation URIs to be first-class resources. They should be used only when someone has asked about the RS URI. So no real need to point back. (to where the client is coming from anyway)

In "Dereference a OOC-NC statement with expiration date by the statement URI, requesting HTML"
I don't see how the last result can return a page customized for an expiration date (the content location in the example is date agnostic, isn't it?)

I'm not sure I get the need for alternate headers.

@aisaac: The Alternates headers are used here when the client requests a statement URL that is 406 Not Acceptable. Just to be clear, is your suggestion that the server should simply respond 406 and decline to provide guidance, or should it make a different response for those resources?

[@aisaac] I'm not sure I get the need for alternate headers.

[@no-reply] @aisaac: The Alternates headers are used here when the client requests a statement URL that is 406 Not Acceptable. Just to be clear, is your suggestion that the server should simply respond 406 and decline to provide guidance, or should it make a different response for those resources?

Correct. I think there was some missing context here, but the motivation for returning 406 Not Acceptable to make sure that there was some way to communicate to a client that a request for a /vocab URI with parameters was invalid.

[@aisaac] In "Dereference a OOC-NC statement with expiration date by the statement URI, requesting HTML" I don't see how the last result can return a page customized for an expiration date (the content location in the example is date agnostic, isn't it?)

Reproducing the diagram above for reference...

When the client requests req1, the server responds with a 406 response in rsp1, including an Alternates header that includes the URI the human-readable representation with the dates. If the client requests that URI as it does in req2, the response rsp2 will be the human-readable representation that includes the expiration date. (I didn't include the body of the response for the sake of brevity.) If this seems like it's in error, let me know.

Could you explain the need for three different URI's /page/ /vocab/ and /data/?

Is it bad practice to solve this through the accept header and deliver the requested data in the format the user requests?

@no-reply, @anarchivist: ok now I think get the alternates. There are a sort of warning that something has gone wrong, not that we're trying to handle something that we allow. I had missed this part of the motivation!

@anarchivist: about the HTML request I understood this diagram, but was puzzled by the fact you "didn't include the body of the response for the sake of brevity.". I was expecting a form of this, or a link to a file that would 'show' the date in its URLs, to make it clear the client is redirected to something that has a date aspect in it.

In both cases I think I'm almost happy now :-)

[@mzeinstra] Could you explain the need for three different URI's /page/ /vocab/ and /data/?

Is it bad practice to solve this through the accept header and deliver the requested data in the format the user requests?

The best (brief) reference I have on this is the Making URIs Dereferenceable section of Linked Data: Evolving the Web into a Global Data Space.

What's listed above is based on my read of the Recipe 6 of the Best Practice Recipes for Publishing RDF Vocabularies referenced in the tech white paper, but basically:

• /vocab/ is the canonical URI base associated with the individual rights statements.
• /page/ is the URI base for the human-readable representation.
• /data/ is a URI base for a specific representation of a given statement.

This follows the pattern that dbpedia uses (as listed in recipe 6), with the exception that we're using /vocab/ instead of /resource/.

We could reduce this further (to just /vocab/ and /page/) if we used hash URIs, but there are caveats/tradeoffs as listed in Making URIs Dereferenceable.

@mzeinstra asked:

Is it bad practice to solve this through the accept header and deliver the requested data in the format the user requests?

Adding to @anarchivist's links; it is bad practice to solve this only through the Accept header. The best short treatment of this I know is buried in a non-normative note in SPARQL Graph Store Protocol. Quoting the gist:

When an HTTP GET is invoked with a request IRI, what is returned and what is its relation to the resource identified by the request IRI? ... If an "http" resource responds to a GET request with a 2xx response, then the resource identified by that IRI is an information resource.

In short, if we respond to /vocab/* with 2xx, we imply that the statements are synonymous with the data/pages about them. The 303 redirects in the interaction diagrams provide a mechanism for resolving this ambiguity in the process of handling the hints in client headers.

Hi all, I've updated this based on the discussion, including @no-reply's comments.