The same resource can have several useful representations without becoming several different things
Content negotiation by profile helps a client request a representation shaped for a particular community or application while keeping media type, profile semantics, caching and fallback behaviour explicit.
HTTP already negotiates media type, language and encoding. A data profile adds another question: which set of structural and semantic constraints should the representation follow? Two JSON documents can share a media type while expressing different subsets, vocabularies or obligations.
Profile negotiation is powerful only when its status and limits are clear. The profile link relation is standardised in RFC 6906. The W3C Content Negotiation by Profile specification describes Accept-Profile and related mechanisms; clients and servers should still document actual support and never assume every intermediary understands profile-aware behaviour.
Chapter contents
- 1. Distinguish resource, representation, media type and profile
- 2. Start with ordinary HTTP negotiation
- 3. Use profile identifiers as stable semantic references
- 4. Advertise profiles with typed links
- 5. Understand Accept-Profile and related response signalling
- 6. Worked example: select a repository metadata view
- 7. Expose available profiles before negotiation
- 8. Combine media type and profile preferences deliberately
- 9. Set Vary and cache keys correctly
- 10. Design defaults, 406 responses and fallbacks
- 11. Protect privacy and constrain parsing
- 12. Validate conformance and govern profile change
Choose a reading route
- Route 1: Separate the layers — resource, representation, media type and profile
- Route 2: Express profiles — profile links and identifiers
- Route 3: Negotiate a response — worked request and selection
- Route 4: Cache and recover — Vary, defaults and fallbacks
- Route 5: Secure and govern — privacy, validation and change
How to use this guide
Start with the chapters that match your immediate decision, then return to the worked example and audit chapters. Each chapter separates a model from the evidence needed to use it responsibly. A claim is not strengthened merely by being technical; it is strengthened when assumptions, observations, alternatives and limits can be inspected.
| Layer | Question | Minimum record |
|---|---|---|
| Concept | What exactly is being represented? | Definitions and boundary |
| Method | How will the reasoning be carried out? | Steps, inputs and assumptions |
| Transfer | Would it work in a changed setting? | A deliberately altered case |
| Audit | What could prove it wrong? | Evidence, limits and revision trigger |
Chapter 1. Distinguish resource, representation, media type and profile
The idea
A resource is the thing identified by a URI; a representation is response data about its current or selected state. Media type describes representation format, while a profile constrains or extends its semantics for a purpose.
A disciplined method
Write one sentence for each layer, list available representations and record which profile claims apply to which response rather than to the abstract resource automatically.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which claim belongs to the resource and which belongs to one representation. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A catalogue record has HTML, generic JSON-LD and a domain-profiled JSON-LD representation. All describe one record, but the profiled response follows additional field rules.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Change the JSON-LD profile without changing the record URI and verify that clients do not create a second intellectual object.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Representations can differ in information content, not merely syntax, and profile conformance can drift.
Evidence to retain: resource URI, response URI, media type, profile identifier, validators and conformance record
Common misconception: A profile is just another media type.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 2. Start with ordinary HTTP negotiation
The idea
HTTP proactive negotiation uses request fields such as Accept, Accept-Language and Accept-Encoding; the origin chooses a response and may signal which request fields influenced it.
A disciplined method
Implement and test standard negotiation first, define server preference and default behaviour, and record exact selection inputs before adding a profile dimension.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which available representation best satisfies the declared preferences. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A client requests application/ld+json ahead of text/html; the server returns JSON-LD and a content type that matches the selected representation.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Remove the preferred type and confirm the server applies its documented fallback or returns an appropriate status.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: HTTP permits server discretion; identical request preferences do not force identical implementations.
Evidence to retain: request fields, available variants, selection algorithm, response headers and fallback
Common misconception: The highest client quality value always overrides server capability and policy.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 3. Use profile identifiers as stable semantic references
The idea
A profile identifier names a set of constraints, conventions or expectations that a representation follows. It should resolve to useful documentation where practical, but it is not necessarily a schema or downloadable file.
A disciplined method
Assign stable HTTP URIs, describe scope and version, separate a profile family from editions and preserve old documentation when constraints change.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is what the identifier commits a producer or consumer to. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A repository publishes one profile URI for its current dataset exchange rules and a versioned URI for a breaking revision.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Move documentation to another server while keeping the profile identifier and redirects stable.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Resolution alone does not prove implementation conformance or semantic compatibility.
Evidence to retain: identifier register, version history, documentation, redirects and deprecation policy
Common misconception: A profile URI must be dereferenced during every response.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 4. Advertise profiles with typed links
The idea
RFC 6906 registers the profile link relation so a representation can indicate that it follows one or more profiles. The link is a semantic claim about the representation.
A disciplined method
Emit Link fields with rel="profile" or equivalent serialisation, preserve context and target, and test that clients associate the profile with the correct response.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which representation the profile link describes. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A JSON-LD response includes a profile link to the community specification, while the HTML response links to a separate presentation profile.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Move links into a Linkset and retain explicit anchors so contexts do not collapse.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: A profile link can be stale, wrong or too broad; clients need conformance evidence.
Evidence to retain: raw Link fields, context, profile URI, response validators and validation result
Common misconception: Linking a profile changes the response media type.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 5. Understand Accept-Profile and related response signalling
The idea
The W3C profile-negotiation specification describes request and response fields for expressing profile preferences and indicating applied profiles. These mechanisms complement rather than replace media-type negotiation.
A disciplined method
Implement only the published syntax and status you actually support, parse preference lists defensively, publish examples and provide a discovery route for clients without header support.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which requested profile was understood and selected. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A client asks for either a compact or archival profile, preferring compact; the server selects compact and signals the applied profile.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Send an unknown profile first and a supported alternative second, then verify preference and fallback rules.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Intermediaries, frameworks or older clients may not recognise profile-specific fields; deployment support must be tested.
Evidence to retain: specification version, raw request, parser result, selection trace and response declaration
Common misconception: Accept-Profile is universally deployed wherever HTTP content negotiation works.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 6. Worked example: select a repository metadata view
The idea
A concrete trace shows media type and profile preferences being evaluated without confusing identity, format or conformance.
A disciplined method
List four available variants, parse Accept and Accept-Profile, eliminate incompatible pairs, apply quality and server rules, return the selected response and record Vary inputs.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which selection rule breaks a tie between compatible variants. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A fictional repository offers generic and archival JSON-LD plus HTML. A client requests JSON-LD with the archival profile; the server returns that representation with Content-Type, profile signalling and validators.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Remove the archival variant and test a generic-profile fallback plus a link to supported profiles.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: The example demonstrates protocol behaviour, not archival or metadata quality.
Evidence to retain: variant table, requests, selection trace, response headers, bytes and validation
Common misconception: Selecting a profile proves every required field is correct.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
| Layer | Client signal | Server evidence |
|---|---|---|
| Format | Accept | Content-Type |
| Profile | Accept-Profile | Applied profile or profile link |
| Cache key | Negotiation fields | Vary |
| Conformance | Profile identifier | Validation report |
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 7. Expose available profiles before negotiation
The idea
Clients need to learn which profiles a server offers. Discovery can use profile links, profile catalogues, Linksets or documented alternate representations.
A disciplined method
Publish a machine-readable list with stable identifiers, labels, media-type compatibility and lifecycle status; keep it consistent with the selector.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which profiles are currently selectable for this resource or endpoint. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A catalogue endpoint lists generic, compact and archival profiles and states that only the first two are available for one record type.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Deprecate one profile and confirm discovery, selection and migration advice change together.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: A global profile list can overstate support for a particular resource.
Evidence to retain: capability document, resource-specific variants, deprecation dates and selection tests
Common misconception: Clients should guess profile URIs from names.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 8. Combine media type and profile preferences deliberately
The idea
A profile does not make an incompatible serialization usable. Selection operates over combinations of media type, profile, language and other dimensions.
A disciplined method
Construct a variant matrix, reject impossible combinations early, define preference ordering and log which dimension caused rejection or fallback.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is how profile preference interacts with media-type quality values. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A client prefers archival JSON-LD, then generic JSON-LD, then HTML; the server has only generic JSON-LD and HTML and chooses the documented second option.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Reverse quality weights and verify selection changes only where alternatives remain compatible.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Complex preference arithmetic is difficult to explain and can produce surprising ties.
Evidence to retain: variant matrix, q values, server weights, exclusions, chosen variant and rationale
Common misconception: A supported profile can be returned in any requested media type.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 9. Set Vary and cache keys correctly
The idea
A shared cache must not serve a representation selected for one request as if it satisfied another. Vary identifies request fields used in selection, while validators distinguish versions.
A disciplined method
Include every material negotiation field in Vary, test shared-cache behaviour, use ETag or Last-Modified per representation and avoid uncontrolled cache-key explosion.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which request fields change the selected response. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
Responses selected by Accept and Accept-Profile include both in Vary; two cached JSON-LD profiles keep separate validators.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Add language negotiation and confirm the cache does not mix language-profile combinations.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Vary can reduce cache efficiency, and some caches may mishandle nonstandard fields.
Evidence to retain: request matrix, cache trace, Vary, Age, validators and revalidation results
Common misconception: Content-Type alone makes a negotiated response cache-safe.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 10. Design defaults, 406 responses and fallbacks
The idea
A server needs explicit behaviour when no offered representation satisfies the request. Silent fallback can help a human browser but mislead an automated client expecting a profile contract.
A disciplined method
Define strict and lenient modes, signal the actual representation, expose available alternatives and use 406 Not Acceptable when the application requires an unmet constraint.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is when fallback is safe and when failure is clearer. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A validation client requests only the archival profile and receives 406 plus available-profile links; a browser with broad preferences receives HTML.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Change the client from interactive to batch ingestion and tighten fallback to protect downstream assumptions.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Some APIs use different error conventions; clients must follow the documented contract.
Evidence to retain: request, mode, status, response headers, available variants and client handling
Common misconception: Returning something is always more interoperable than returning 406.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 11. Protect privacy and constrain parsing
The idea
Detailed negotiation preferences can reveal client capabilities or communities, while profile identifiers and targets are untrusted inputs. Servers and clients need limits.
A disciplined method
Minimise preference detail, cap header and list sizes, allowlist schemes, avoid fetching arbitrary profile URIs, normalise safely and log without leaking sensitive headers.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is which information is necessary for selection and which creates fingerprinting risk. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A client sends two purpose-relevant profiles rather than its entire installed capability catalogue; the server parses within bounded limits.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Route the same request through a shared proxy and inspect which fields are logged or forwarded.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: Privacy risk depends on combination with other signals; strict limits can reduce flexibility.
Evidence to retain: threat model, parser tests, size limits, logs, retention and security incidents
Common misconception: Profile URIs are safe metadata and may always be dereferenced.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Chapter 12. Validate conformance and govern profile change
The idea
Negotiation chooses a claimed variant; validation tests whether it meets the profile. Profiles and implementations change, so monitoring must connect selection, conformance and client compatibility.
A disciplined method
Validate representative responses, publish profile versions, test old clients, use deprecation windows and trigger review when fields, selection rules or cache behaviour change.
A useful working record makes the sequence visible: first state the question and unit of analysis; next record the observations and their provenance; then apply the stated rule; finally compare the result with plausible alternatives. For this chapter, the decisive choice is what proves the selected response still meets its declared profile. Keeping that choice explicit prevents a later reader from mistaking a convenient convention for a fact about the world.
Worked example
A deployment selects the archival variant correctly but omits a mandatory provenance field; monitoring catches the conformance failure separately.
Work the example twice. On the first pass, follow the stated assumptions. On the second, reverse one assumption, remove one piece of evidence and ask whether the conclusion, ranking or boundary changes. This small stress test matters because polished outputs can hide sensitivity. The objective is not to force certainty; it is to locate the evidence on which the conclusion actually turns.
Changed-context transfer check
Introduce a breaking profile revision and test dual publication before retiring the old edition.
A transfer succeeds only when the structure of the problem survives the change. Match roles, dependencies and measurement conditions rather than surface vocabulary. Record what was preserved, what changed, and why the method still applies—or why it does not. If the new context changes the data-generating process or the people bearing the burden, re-specify the model instead of importing the old answer.
Limits, evidence and revision
Limit: No validator can prove every semantic claim or downstream fitness.
Evidence to retain: profile rules, validator version, sample responses, compatibility tests, incidents and migration record
Common misconception: Successful negotiation is equivalent to successful validation.
A gold-standard conclusion is therefore conditional. It should name the observation period, excluded cases, uncertainty and the event that would trigger review. Negative findings and unresolved contradictions belong in the record. They protect future readers from repeating a hidden assumption and make correction possible without reconstructing the entire analysis from memory.
Practical evidence check
Can another reader recover the input, reproduce the intermediate decision and identify at least one observation that would change the result? If not, the chapter has produced an explanation but not yet an auditable finding.
Field workbook
Model one resource with HTML, generic JSON-LD and profiled JSON-LD variants. Write the Accept and Accept-Profile preferences, selection table, response headers, Vary fields and a 406 case. Then change the profile version and plan migration.
- Write the decision question in one sentence and name the decision owner.
- List observations separately from interpretations, with dates and provenance.
- Record at least two plausible alternatives before choosing a preferred account.
- Run the changed-context test and note which assumptions fail.
- State the limit, confidence and next review trigger in plain language.
| Layer | Evidence | Failure signal |
|---|---|---|
| Identity | One resource and variant map | Representation treated as new object |
| Selection | Parsed preferences and trace | Undocumented fallback |
| Caching | Vary and validators | Cross-profile cache mix |
| Conformance | Versioned validation | Claim without evidence |
Continue through the verified ecosystem
- Signposting — typed links and repository discovery
- Memento — datetime negotiation and representation history
- RO-Crate — profiled portable research objects
- IIIF — interoperable digital-object representations
- Schema evolution — compatibility and semantic drift
Frequently asked questions
What is a data profile?
A named set of constraints or conventions that shapes the content and semantics of a representation for a purpose.
Is a profile a media type?
No. Several profiles can use the same media type, and one profile may allow several media types.
What does rel="profile" mean?
It links a representation to a profile that describes additional constraints or conventions it follows.
Why is Vary important?
It tells caches which request fields influenced representation selection so incompatible variants are not mixed.
Should a client fetch every profile URI?
No. The identifier can be used without automatic retrieval, and arbitrary targets require security controls.
Does successful negotiation prove conformance?
No. Selection chooses a claimed variant; validation provides separate evidence about the claim.
Authoritative sources and further reading
- RFC 9110: HTTP Semantics — representations, negotiation and Vary semantics
- RFC 6906: The profile Link Relation Type — standard profile relation
- W3C: Content Negotiation by Profile — profile preferences and selection mechanisms
- W3C: The Profiles Vocabulary — describing profiles and resources
- RFC 9111: HTTP Caching — cache selection and validation
This guide explains representation selection and profile signalling. It does not guarantee that every client, proxy or framework implements profile-specific mechanisms, or that a selected representation conforms semantically.