Re: [dxwg] Define conneg interaction with media types that have a profile param

>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 `Unknown`but 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)


-- 
GitHub Notification of comment by azaroth42
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/261#issuecomment-435325246 using your GitHub account

Received on Friday, 2 November 2018 09:46:32 UTC