Define conneg interaction with media types that have a profile param

[azaroth42]

Some media types already have a profile parameter, such as JSON-LD. The profile negotiation deliverable should define how conflicts between it's syntax and profiles specified in the media type are handled.

For example, a server would need to deterministically handle:

GET /foo/bar HTTP/1.1

Accept: application/ld+json;profile="http://example.org/profile/jsonld"
Accept-Profile: http://baz.com/some/other/profile

(edited to fix header name)

[nicholascar]

I think the proposed HTTP header is Accept-Profile, not Accept-Schema?

Will this likely be solved by just establishing an order of precedence for profiles? In the case of multiple requests across protocols (e.g. HTTP header & URI query string arg) that which has been set by a human will override a machine request so ?_format=text/turtle overrides Accept: applications/rdf+xml if both are present. Is this the sort of solution imagined here?

[azaroth42]

Yes, sorry -- Accept-Profile (I always get it round the wrong way, as the document's URL has accept-schema in it ... twice! Edited the issue text to fix this.

The issue is that there needs to be a rule to determine the precedence between the HTTP headers that can carry the same information. Within a single header, q values can be used. The multiple protocol issue becomes even more complex.

There are four options that I can see:

• It is a client error to send both Accept and Accept-Profile, when the Accept header contains items that have a profile media type parameter or functional equivalent. I don't think this is the way to go, as there are existing systems that rely on (e.g.) json-ld's profile parameter to request particular syntaxes (flattened vs expanded, web-annotation versus activity-streams). If there was another syntax (e.g. turtle) that did not have a profile parameter, it would be impossible to ask for one of JSON-LD with the profile (in Accept) or Turtle (in Accept) with the same profile (in Accept-Profile).
• The Accept-Profile header takes precedence. This is good for forwards compatibility. The new thing overrules the old thing, that existed before we had this capability.
• The Accept header takes precedence. This is good for backwards compatibility. The old thing is well established and in use, the new thing should layer on top of it but not break it.
• Precedence is explicitly defined by the server. This would make sense as the conneg algorithm is already server-specific. It is, however, bad for interoperability as the results between systems can be very dissimilar in the presence of the same information. I don't think this is the right way to go, as it's not about weighting of various options, it's about resolving an explicit conflict.

My personal opinion (not speaking as chair of or on behalf of the JSON-LD WG) is that Accept should take precedence as breaking existing systems is to be avoided whenever possible.

[nicholascar]

I agree that in the event of two conflicting headers, the more established one should take precedence (so Accept over Accept-Profile) unless it’s more likely that one is a deliberate choice, the other a config artifact.

Can we say that scheme selection in Accept headers is common or often used? Is it used elsewhere other than in JSON-LD? Knowledge of such practice (I don’t have it) will assist in determining sensible precedence.

[larsgsvensson]

I too agree that it would make more sense to let Accept take precedence over Accept-Profile, even if I don't think that there will be much overlap.

@nicholascar wrote:

Can we say that scheme selection in Accept headers is common or orften used? Is it used elsewhere other than in JSON-LD? Knowledge of such practice (I don’t have it) will assist in determining sensible precedence.

The use of the profile parameter (or any parameter) in the Accept header is only possible when specified in the media type registration (cf. RFC 2048):

2.2.3.  Parameter Requirements

   Media types may elect to use one or more MIME content type
   parameters, or some parameters may be automatically made available to
   the media type by virtue of being a subtype of a content type that
   defines a set of parameters applicable to any of its subtypes.  In
   either case, the names, values, and meanings of any parameters must
   be fully specified when a media type is registered in the IETF tree,
   and should be specified as completely as possible when media types
   are registered in the vendor or personal trees.

I don't know about all media types, but of the RDF-relevant ones only JSON-LD (application/ld+json) specifies the use of a profile parameter

[nicholascar]

From the IETF submission I thought this mechanism was discussed (use of profile in Accept) and use of Accept-Profile chose instead.

Should we be looking to bring JSON-LD into new, shared, mechanics of Accept-Profile rather than catering for it as a one-off?

[azaroth42]

The W3C is responsible for the registration of application/ld+json and the JSON-LD WG could update it to give precedence to Accept-Schema, when there's an RFC for it.

[azaroth42]

@azaroth42 to add additional use cases specific to JSON-LD here.

[azaroth42]

From discussion at TPAC, adding JSON-LD relevant scenarios:

Given the graph,

<https://example.org/graph/1> a schema:Person ;
  schema:name "Rob Sanderson"

available at https://example.org/graph/1

1. Client has no preferences

The server has some data (as per example above) and wants to make it available.

The server must be able to do what it wants, in the case of no content negotiation preferences expressed by the client. It must be able to express the choice it has made, if any. It should be able to express a way to discover the other options for retrieval.

Request: No additional headers.

Response:

Content-Type: application/ld+json;profile="https://example.org/contexts/schema.jsonld"

{
  "@context": "https://example.org/contexts/schema.jsonld",
  "id": "https://example.org/graph/1",
  "type": "Person",
  "name": "Rob Sanderson"
}

Status: This works today, using the Content-Type header. Discovery of options is not currently specified, nor implemented, to my knowledge.

2. Client requests server-known context

The client wants to have the same RDF data, but in an alternative context to change the representation to use the keys it knows.

Request:

Accept: application/ld+json;profile="https://example.org/contexts/alternative.jsonld"

Response:

Content-Type: application/ld+json;profile="https://example.org/contexts/alternative.jsonld"

{
  "@context": "https://example.org/contexts/alternative.jsonld",
  "@id": "https://example.org/graph/1",
  "type": "schema:Person",
  "name": "Rob Sanderson"
}

Status: This works today, using the Accept and Content-Type headers.

3. Client requests specification defined profile

JSON-LD 1.0 defines several profiles for different forms of the data, such as the difference between compacted and expanded. Expanded JSON-LD does not have a context, all of the information needed to construct the triples is present in the data.

Request

Accept: application/ld+json;profile="http://www.w3.org/ns/json-ld#expanded"

Response:

Content-Type: application/ld+json;profile="http://www.w3.org/ns/json-ld#expanded"

[
  {
    "@id": "https://example.org/graph/1",
    "http://schema.org/name": [
      {
        "@value": "Rob Sanderson"
      }
    ],
    "@type": [
      "http://schema.org/Person"
    ]
  }
]

4. Client requests a server-known frame

Frames allow the restructuring of the graph and the addition of default values if not present in the data instance. Frames have a context, and hence these are not orthogonal. Assuming a frame, with the URI https://example.org/frames/desc.jsonld that added a default value for schema:description of Unknownbut otherwise uses the context from the first scenario...

Request:

Accept: application/ld+json;profile="https://example.org/frames/desc.jsonld"

Response:

Content-Type: application/ld+json;profile="https://example.org/frames/desc.jsonld"

{
  "@context": "https://example.org/contexts/default.jsonld",
  "@id": "https://example.org/graph/1",
  "type": "schema:Person",
  "name": "Rob Sanderson",
  "description": "Unknown"
}

5. Client requests profile with URI unknown to the server

The client might put a URI in to the profile parameter that the server does not recognize. In this scenario, the server might choose to retrieve the representation from that URI and attempt to process it as a context or frame (currently distinguished via the Content-Type on the response).

This scenario resolves to scenarios 2 or 4, but with additional complexity for the server to complete the request. The server must be able to express that it did not attempt to dereference the URI, and instead delivered different data.

6. Client requests a profile that would change the predicates, without changing the semantics

And here I feel we leave the JSON-LD space and enter the Accept-Profile space.

Clients might wish to retrieve the same resource, but using different ontologies rather than just different surface syntax via JSON-LD contexts. For example, instead of schema.org, the client might prefer FOAF or Dublin Core or CIDOC-CRM. This would be orthogonal to context/frame, as each ontology's representation might have several different contexts. It is also orthogonal to media type, as the triples could be retrieved in Turtle, RDF/XML or other serializations.

Request:

Accept: application/ld+json;profile="https://example.org/contexts/dc.jsonld"
Accept-Profile: https://example.org/profiles/dc

Response:

Content-Type: application/ld+json;profile="https://example.org/contexts/dc.jsonld"
Content-Profile: https://example.org/profiles/dc

{
  "@context": "https://example.org/contexts/2.jsonld",
  "id": "https://example.org/graph/1",
  "type": "Agent",
  "title": "Rob Sanderson"
}

(@gkellogg @BigBlueHat @iherman @ajs6f)