### JSON-LD Example with Hash Prefix

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2018-02-05/index.html

Illustrates a JSON-LD structure where a key starts with a hash symbol, which requires specific vocabulary handling or might be ignored if not set up correctly.

```json
{
  "#Foo": "bar"
}
```

--------------------------------

### JSON-LD Compaction Configuration Examples

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-08-21/index.html

Examples illustrating different configurations for JSON-LD compaction, specifically focusing on the 'compact' property and its potential values (boolean or integer). These examples are part of a discussion on how to handle property generation and compaction in JSON-LD.

```JSON
{
  "foo": {
    "@id": "[any match in here]",
    "compact": true
  }
}
```

```JSON
{
  "foo": {
    "@id": "[any match in here]",
    "compact": 1
  }
}
```

```JSON
{
  "foo": {
    "@id": "[any match in here]",
    "compact": 5
  }
}
```

--------------------------------

### RDF-star Examples with Annotations

Source: https://github.com/json-ld/minutes/blob/main/2023-05-31/index.html

Provides examples of RDF-star syntax for annotating triples, including quoted predicate-object pairs and general annotations. These examples showcase how to attach metadata such as probability and source information to statements.

```rdf-star
{$Id: joe, rdfs:label: Hacker}
Probability: 0.5
Prov:wasDerivedFrom: joehacker.org
```

```rdf-star
<X> a :Organization {| :statedIn <v2> |} ;
% A :Person {| :statedIn <v1> ; :retractedIn <v2> |} ;
% :Employs <y> {| :suggestedBy <q> {| :statedIn <v2> |} |} .
```

```rdf-star
$Id: joe
$Quoted:
Rdfs:label: Hacker
$Annotation:
Probability: 0.5
Prov:wasDerivedFrom: joehacker.org
```

--------------------------------

### YAML-LD-Star Syntax Example

Source: https://github.com/json-ld/minutes/blob/main/2023-05-31/index.html

An example syntax discussed for YAML-LD-Star, potentially for annotating data. This syntax was proposed as a possible representation for YAML-LD-Star.

```APIDOC
{$Id: joe, rdfs:label: Hacker}: {probability: 0.5}
```

--------------------------------

### Turtle Syntax Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-01-22/index.html

A brief example demonstrating how a specific relationship ('rateType') and its value ('FlatAmount') might be expressed in Turtle syntax, used for comparison in the JSON-LD discussion.

```turtle
<...> :rateType :FlatAmount .
```

--------------------------------

### JSON-LD Context with Options

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-04-16/index.html

A structural example of a JSON-LD context object, showcasing the use of the '@options' key for configuration settings within the context definition.

```JSON
{
  "@context": {
    "@options": {
      // ... configuration details ...
    }
  }
}
```

--------------------------------

### JSON-LD Data Annotations: Example Removal and Replacement

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-01-29/index.html

This snippet details the proposal and resolution to remove 'Example 51: Data annotations' from the JSON-LD documentation. The goal is to replace it with new examples that better demonstrate how data annotations survive the expansion and compaction processes.

```APIDOC
Example Modification Proposal:

Action: Remove Example 51: Data annotations.

Reasoning:
- The current example may not accurately reflect the intended usage or best practices for data annotations in JSON-LD.
- There is a need to provide clearer examples that illustrate the round-tripping of data annotations through expansion and compaction.

Proposed Replacement:
- Develop and include new examples that specifically showcase how data annotations are preserved during JSON-LD processing.
- These examples should align with the clarified purpose of keywords like @index.

Related Context:
- Discussion on the naming and purpose of annotation-like keywords.
- Ensuring developers mark up data correctly as Linked Data.
```

--------------------------------

### JSON and RDF Examples

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-05-08/index.html

Illustrative examples of JSON data and RDF triples discussed in the context of API behavior and data representation.

```JSON
{
  "@id": "#foo",
  "@type": "bar"
}
```

```Turtle
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
<#foo> a <bar> .
```

--------------------------------

### JSON-LD API Introduction Discussion

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-06-05/index.html

Discussion points regarding the JSON-LD API specification, including feedback from the RDF WG and proposed content for the introduction. This covers the need for basic API functionality with simple code examples and examples of converting to and from RDF.

```APIDOC
JSON-LD API Specification:

Key Requirements for Introduction:
  - Introduction to basic API functionality with simple code examples.
  - Examples of converting to RDF from JSON-LD.
  - Examples of converting to JSON-LD from RDF.

Discussion on Publishing:
  - The RDF WG wants to publish the JSON-LD API spec.
  - Proposal to publish the JSON-LD API spec without framing for initial review.

Related Concepts:
  - .objectify() call: A proposed method to get an object graph back with interconnections in place, similar to a Projection.
  - .toJSON() method: Used in an in-memory object graph implementation to produce a JSON-LD tree.
  - Contextualization: Using a JSON-LD context is valuable for working with objects programmatically.
  - RDFa API to JSON-LD API conversion: Discussed in relation to green-turtle.js and jsonld.js, focusing on converting from RDF to JSON-LD.
```

--------------------------------

### Media Type Usage Examples

Source: https://github.com/json-ld/minutes/blob/main/2024-04-03/index.html

Examples of media types used for JSON-LD, including custom suffixes and profile parameters, discussed in the context of web data representation and API integration.

```APIDOC
application/github+ld+json
  - Custom media type suffix for GitHub API output interpreted as JSON-LD.

application/ld+json;profile={context_url}
  - Standard media type for JSON-LD, extended with a profile parameter to specify a context URL.
    Used by Web Annotation WG.

application/ld+json
  - Base media type for JSON-LD data.
```

--------------------------------

### JSON-LD Expansion and Compaction Round-trip Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-08-21/index.html

An example demonstrating a scenario in JSON-LD where a key ('foo') might expand into multiple IRIs ('a', 'b'). It poses questions about duplicate removal and round-trip validity during compaction, reflecting discussions on complex property generation and data integrity.

```JSON
{
  "foo": [
    "a",
    "b"
  ]
}

// Discussion context:
// foo: data - expand - a: data, b: data
// - compact - foo: data, data ??? Remove duplicates, round-trip OK?
```

--------------------------------

### JSON-LD @context Syntax Examples and Proposals

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2011-11-15/index.html

This snippet presents various syntax examples and proposals discussed for defining JSON-LD @context. It covers the use of @vocab, prefix mappings, and specific ways to define IRIs and datatypes for terms.

```json
{
  "foaf": "http://xmlns.com/foaf/0.1/",
  "dc": "http://purl.org/dc/terms/"
}
```

```json
{
  "a": "b:c",
  "b": "a:c"
}
```

```json
{
  "@context": [
    {
      "foaf": "http://xmlns.com/foaf/0.1/",
      "dc": "http://purl.org/dc/terms/"
    },
    {
      "title": "dc:title",
      "homepage": "foaf:homepage"
    }
  ]
}
```

```json
{
  "created": {
    "@iri": "http://purl.org/dc/terms/created",
    "@coerce": "xsd:dateTime"
  }
}
```

```json
{
  "created": {
    "@iri": "http://purl.org/dc/terms/created",
    "@type": "xsd:dateTime"
  }
}
```

```json
{
  "created": {
    "@iri": "dc:created",
    "@datatype": "xsd:dateTime"
  }
}
```

```json
{
  "created": [
    "http://purl.org/dc/terms/created",
    {
      "@type": "xsd:dateTime"
    }
  ]
}
```

```json
{
  "created": [
    "http://purl.org/dc/terms/created",
    {
      "@coerce": "xsd:dateTime"
    }
  ]
}
```

```json
{
  "created": {
    "dc:created": "xsd:dateTime"
  }
}
```

```json
{
  "created": {
    "http://purl.org/dc/terms/created": "http://www.w3.org/2001/XMLSchema#dateTime"
  }
}
```

```json
{
  "created": {
    "@iri": "dc:created",
    "@datatype": "xsd:dateTime",
    "@array": "@list"
  }
}
```

```json
{
  "created": {
    "@iri": "dc:created",
    "@datatype": "xsd:dateTime",
    "@list": true
  }
}
```

```json
{
  "created": {
    "@iri": "dc:created",
    "@datatype": "xsd:dateTime",
    "@rev": true,
    "@set": true
  }
}
```

--------------------------------

### EARL Report URL Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-04-23/index.html

Provides a direct URL to an EARL (Easy RDF Assertion Language) report for RDF Turtle tests. This serves as an example of the format and location for implementation reports.

```url
https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/rdf.rb-earl.ttl
```

--------------------------------

### JSON-LD Context Definition Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-08-21/index.html

An example of a JSON-LD context definition that might be used to declare a term as a prefix. This syntax is discussed in the context of managing prefixes and terms, and how they might be explicitly defined or controlled.

```json
{
  "@context": {
    "@vocab": "http://example.org/",
    "foaf": {
      "@id": "http://xmlns.com/foaf/0.1/",
      "@prefix": true
    }
  }
}
```

--------------------------------

### JSON-LD @id Relative Path Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2018-02-26/index.html

Demonstrates how a property can be defined with a relative path in JSON-LD, illustrating the context of IRI resolution discussions.

```json
{"@id": "some/path"}
```

--------------------------------

### JSON-LD Term Concatenation Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2018-02-05/index.html

Explains the behavior of string concatenation for terms in JSON-LD, particularly when a vocabulary IRI ends with a hash ('#'). This ensures keys and type values can be handled correctly without needing to start with a '#'.

```APIDOC
JSON-LD Term Concatenation:
  When a vocabulary IRI ends with '#', terms are string-concatenated with the vocabulary base.
  This behavior is similar to prefix handling in Trig/Turtle, RDFa, and RDF/XML.
  Example:
    If @vocab is "http://example.org/#", and a term is "myterm", the resulting IRI is "http://example.org/myterm".
    This allows keys (and type values) to be handled without necessarily starting with a '#'.
```

--------------------------------

### HTTP to HTTPS Transition and Namespace Handling

Source: https://github.com/json-ld/minutes/blob/main/2024-09-23/index.html

Discusses challenges and strategies related to the transition from HTTP to HTTPS for ontologies and namespace management.

```APIDOC
Ontology and Namespace Handling (HTTP/HTTPS):

Transition Challenges:
  - Many systems broke when W3C moved from HTTP to HTTPS.
  - Publishers of HTTP ontologies face user demand for HTTPS.
  - Hacks are sometimes needed to reconcile HTTP and HTTPS endpoints.

Namespace Best Practices:
  - Require namespaces to be within a common base URL (e.g., w3.org/ns).
  - This allows using names without worrying about HTTP vs. HTTPS prefixes.
```

--------------------------------

### JSON-LD Issue Closure Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/index.html

An example of closing an issue (ISSUE-159) by referencing another issue (ISSUE-133) and stating no further actions are required.

```APIDOC
Issue Management:
  - Action: Close ISSUE-159.
  - Rationale: By referencing ISSUE-133.
  - Outcome: No further actions required.
```

--------------------------------

### Turtle-star Example with Annotations

Source: https://github.com/json-ld/minutes/blob/main/2023-05-31/index.html

Demonstrates the use of Turtle-star syntax for annotating triples, specifically showing how to associate metadata like ':source' with a triple. The '|' syntax is used to enclose annotations.

```turtle-star
:Linkoping :population 1234 {| :source :wikidata |} .
:Linkoping :population 01234 {| :source :wikidata |} .
```

--------------------------------

### JSON-LD expand() and compact() Method Signatures and Options

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-10-23/index.html

This entry documents the proposed changes to the JSON-LD processor's expand and compact methods. The discussion centers on unifying parameter handling by moving the optional context parameter into a JsonLdOptions object, introducing an 'expansionContext' option for both methods. This aims to simplify method signatures and provide consistent behavior for context management during expansion and compaction operations.

```APIDOC
Method: expand

Previous Signature Discussion:
void expand (object or object[] or IRI input, object or IRI? context, JsonLdCallback callback, optional JsonLdOptions? options);

Proposed Signature:
void expand (object or object[] or IRI input, JsonLdCallback callback, optional JsonLdOptions? options);

Rationale:
- The 'context' parameter is moved into the 'options' object as 'expansionContext'.
- This change simplifies the primary signature and allows for more flexible option passing.
- It addresses concerns about explicitly naming functions after their intended use and avoids potential confusion.

Parameters:
- input: The JSON-LD document, array of documents, or IRI to expand.
- callback: A callback function to handle the result.
- options: An optional object containing configuration settings.
  - expansionContext: (Optional) The context to be used for expansion. This replaces the direct 'context' parameter.

Related Methods:
- compact(): The 'expansionContext' option is also proposed to be available for the compact() method when expansion is performed internally before compaction.

Example Usage (Conceptual):
// Assuming JsonLdOptions is defined and expansionContext is a property
processor.expand(myDoc, { expansionContext: myContext }, (err, expandedDoc) => { ... });

Method: compact

Previous Signature Discussion:
void compact (object or object[] or IRI input, object or IRI context, JsonLdCallback callback, optional JsonLdOptions? options);

Proposed Change:
- The 'context' parameter for compact() should also accept the 'expansionContext' from the options object when expansion is performed internally.

Rationale:
- To maintain consistency, if expansion is a prerequisite for compaction, the same 'expansionContext' option used in expand() should be applicable.

Parameters:
- input: The JSON-LD document, array of documents, or IRI to compact.
- context: The context to use for compaction. Can be influenced by 'expansionContext' in options.
- callback: A callback function to handle the result.
- options: An optional object containing configuration settings.
  - expansionContext: (Optional) The context to be used for initial expansion before compaction.

Resolution:
Move the optional expansion context parameter in the .expand() call into the last JsonLdOptions parameter. This option will also be used in the .compact() call (when expanding before compacting).
```

--------------------------------

### JSON Object Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2011-07-04/index.html

An example of a simple JSON object representing an entity, highlighting the need for identifiers or blank node concepts in data modeling.

```JSON
{
  "name": "Bradley Allen"
}
```

--------------------------------

### JSON-LD SubPropertyOf Assertion Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-10-02/index.html

An example showing how a property generator relationship could be represented using `rdfs:subPropertyOf` during expansion, as an alternative to direct expansion.

```jsonld
{
  "@id": "http://bar.com/baz",
  "rdfs:subPropertyOf": "http://schema.org/title"
}
```

--------------------------------

### Context JSON-LD Document Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2011-10-04/index.html

Shows an example of a document that serves as a JSON-LD context itself. It may contain its own @context definitions, potentially referencing other remote contexts.

```json
{
  "@context": [
    "http://thiswouldnotload.example.com/othercontext.jsonld",
    {
      "bar": "http://bar.org/bar#"
    }
  ]
}
```

--------------------------------

### Test Suite Manifest Index URL Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-04-23/index.html

Links to an index page for test suite manifests, likely containing information about different test sets and their associated reports. This is relevant for understanding test suite organization.

```url
https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/index.html
```

--------------------------------

### JSON-LD Structure Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-09-11/index.html

An example of a JSON-LD structure illustrating the representation of resources and authors with language-specific identifiers. This snippet demonstrates a basic JSON-LD context and data structure.

```JSON-LD
{
  "@context": {
    "@id": "/resource",
    "author": {
      "http://example.com/en": {
        "@id": "/lin"
      },
      "http://example.com/de": {
        "@id": "/stephane"
      }
    }
  }
}
```

--------------------------------

### JSON-LD Expansion with Property Generators and BNodes

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-10-02/index.html

An example illustrating the expansion of a context with property generators, where bnodes must have node-ids to facilitate comparison after compaction.

```jsonld
{
  "@context": {
    "term": {
      "@id": [
        "http://example.org/vocab#term1",
        "http://example.org/vocab#term2"
      ]
    },
    "label": "unknown"
  }
}

// Expands to:
// [
//   {
//     "@id": "_:genid-1",
//     "http://example.org/vocab#term1": {
//       "@id": "_:genid-1"
//     }
//   },
//   {
//     "@id": "_:genid-1",
//     "http://example.org/vocab#term2": {
//       "@id": "_:genid-1"
//     }
//   },
//   {
//     "@id": "_:genid-1",
//     "label": "unknown"
//   }
// ]
```

--------------------------------

### Contextual Marking for Compaction

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-08-21/index.html

Explores an alternative solution to combinatorial .compact() by allowing explicit marking of terms within the @context to guide the compaction algorithm, simplifying the process for developers.

```APIDOC
ALTERNATIVE SOLUTION: MARKING TERMS IN @CONTEXT FOR COMPACTION

Proposal: Mark which term to use in the compaction within the @context, allowing the compaction algorithm to simply look there and pick the specified term.

Example Structure 1:
{
  "@context": {
    "foo": {
      "compact": true,
      // ... other stuff here ...
    }
  }
}

Example Structure 2 (Explicitly defining property generator compaction):
"foo": {
  "@id": "whatever",
  // ... property generator definition ...
  "compact": true
}

Benefit: Makes compaction super simple and explicit, allowing developers to be clear about compaction choices without needing deep understanding of the underlying algorithm. It can also incorporate ranking algorithms into the context for explicit term selection.
```

--------------------------------

### JSON-LD Syntax Specification Review Points

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-03-19/index.html

Summarizes key points from syntax specification reviews, including handling of @base, @vocab, and the relationship with RDF conversion tools.

```APIDOC
Syntax Specification Review Points:

  1. @base and @vocab Usage:
     - Concern: How @base and @vocab are used in relation to relative IRIs.
     - Risk Acknowledged: @base is marked as at-risk; potential risk with over-reliance on expansion.

  2. RDF Conversion Tools (Conformance Section):
     - Proposed additions to conformance section: JSON-LD Expander, JSON-LD Compacter, JSON-LD To-RDF-Converter, JSON-LD From-RDF-Converter.
     - Discussion: These belong in the syntax specification, not the API specification.
     - Decision: No change to conformance section based on current understanding.

  Related Concepts:
    - Context processing in JSON-LD.
    - Relative IRI resolution.
```

--------------------------------

### RDF Literal with Datatype Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2011-12-13/index.html

This example demonstrates how a literal value, specifically a date string, is represented in RDF with an associated datatype (xsd:date). This format was referenced during the discussion about value spaces.

```rdf
"2011-12-13"^^xsd:date
```

--------------------------------

### JSON-LD Remote Context with @base Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-05-07/index.html

Illustrates a scenario involving a document including a remote context, both with @base declarations. This example is used to discuss the resolution of the @base directive and its scope.

```json
[
  {
    "@context": "[http://example.com/dir/remote-context.jsonld"](http://example.com/dir/remote-context.jsonld/)
  },
  "/dir/remote-context.jsonld"
]

// Content of /dir/remote-context.jsonld:
{
  "@context": {
    "@base": "./"
  }
}
```

--------------------------------

### JSON-LD API: .compact() and .expand() Method Behavior

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/index.html

Details on how the .compact() and .expand() methods in the JSON-LD API should handle contexts and parameters. This includes processing order for contexts and base IRI resolution for @type.

```APIDOC
JSON-LD API Methods:

.expand(input, options)
  - Expands a JSON-LD document.
  - Parameters:
    - input: The JSON-LD document to expand.
    - options: An object containing processing options.
      - expandContext: An optional context to be applied during expansion.

.compact(input, context, options)
  - Compacts a JSON-LD document.
  - Parameters:
    - input: The JSON-LD document to compact.
    - context: The context to use for compaction.
    - options: An object containing processing options.
      - expandContext: An optional context to be applied first during the internal expansion phase of compaction.

Resolutions affecting API behavior:

- ISSUE-156: Compact API first expands without provided context. Process the 'expandContext' option when performing .compact(). When expanding during the .compact() call, the 'expandContext' is applied first, followed with any other contexts held in the document being processed.
- ISSUE-162: Base IRI used to expand @type. When resolving IRIs for @type, first use a term/prefix if that exists, if not use @vocab, if @vocab does not exist, use the BASE IRI to resolve @type. Do not define @vocab as base IRI but as prefix.
- ISSUE-168: JSON-LD Syntax document MUST utilize the RDF definitions.
- ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core Processing.
- ISSUE-133: Add '@language' container type (related to ISSUE-159). The values of the key-value pairs of a language map MUST be strings or arrays of strings. When expanded, the strings are tagged with the language specified by the key. When compacting, only language-tagged strings will match a term that has a "@container": "@language" mapping. Terms that have a "@container": "@language" mapping MUST NOT be type-coerced.
```

--------------------------------

### JSON-LD Compaction/Expansion Value Splitting Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-04-03/index.html

Illustrates how JSON-LD values can be split across different terms during compaction based on type specificity. This example shows an expanded form and its potential compacted representation.

```APIDOC
API Documentation: JSON-LD Value Splitting and Merging

This documentation describes the behavior of JSON-LD compaction and expansion, specifically how values are handled when multiple terms apply or when partitioning by datatype.

**Scenario: Splitting values during compaction**

When an expanded JSON-LD document contains a value that can be mapped to multiple terms (e.g., an integer, a float, and a datetime), compaction might need to split these values into separate properties.

*   **Expanded Form Example:**
    ```json
    {
      "http://example.com/foo": [
        1,
        "a",
        {
          "@id": "/bar"
        }
      ]
    }
    ```

*   **Context Definition Example:**
    ```json
    {
      "@context": {
        "foo_int": {
          "@id": "http://example.com/foo",
          "@type": "xsd:integer"
        },
        "foo_string": {
          "@id": "http://example.com/foo",
          "@type": "xsd:string"
        },
        "foo_ref": {
          "@id": "http://example.com/foo",
          "@type": "@id"
        }
      }
    }
    ```

*   **Potential Compacted Form:**
    The values from the expanded form are split among the most specific terms:
    ```json
    {
      "foo_int": 1,
      "foo_string": "a",
      "foo_ref": "/bar"
    }
    ```

**Considerations:**

*   **Order of Arrays:** The order of values in arrays in the expanded form does not matter for merging during expansion, but tests might be sensitive to it.
*   **Term Selection:** When multiple terms apply, a mechanism (potentially lexicographical comparison or a defined algorithm) is needed to select the most appropriate term or to split values.
*   **Non-compacted Form:** If there's ambiguity or no clear term applies, the non-compacted form (using IRIs) might be used.
*   **CURIE Minting:** If information is available to mint a CURIE, it should be preferred over using raw IRIs.
*   **Algorithm:** Reference is made to an algorithm by Dave Longley for combining/splitting values.
```

--------------------------------

### W3C Recommendation Track Process

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-08-20/index.html

Details the stages and procedures for advancing a W3C technical specification through the Recommendation Track. Covers the transition from Candidate Recommendation (CR) to Proposed Recommendation (PR), including objection periods, review meetings, director approval, and the option to skip CR for a direct PR transition.

```APIDOC
W3C Recommendation Track Process:

1.  **Candidate Recommendation (CR) Stage**:
    *   **Announcement**: Specification is published as a Candidate Recommendation.
    *   **Objection Period**: A defined lag period (e.g., 7 days) is observed for stakeholders to raise objections.
    *   **Review & Approval**: Meetings with W3C staff, editors, and chairmen occur. Director's approval is required for progression.
    *   **Publish Date**: Specification is officially published as CR.

2.  **Transition from CR to Proposed Recommendation (PR)**:
    *   **Process**: Similar to CR transition, involving announcement, objection period, reviews, and director approval.
    *   **Alternative: Skip CR to PR**: Possible if all 'at-risk' items are resolved prior to the CR stage.
    *   **Considerations for Skipping CR**: 
        *   Ensuring sufficient time for testing and implementation reports.
        *   Avoiding perceptions of rushing or 'railroading' the standard.
        *   Allowing major adopters (e.g., Google) adequate time to respond.
    *   **Timeline Management**: Adjusting lag periods to meet deadlines or accommodate feedback.

3.  **Proposed Recommendation (PR) Stage**:
    *   **Process**: Upon successful transition from CR (or direct from LC), the specification enters the PR stage, requiring a similar review and approval cycle to become a W3C Recommendation.
```

--------------------------------

### JSON-LD @coerce Example: List of IRIs

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2011-10-18/index.html

Illustrates a proposed JSON-LD syntax for specifying that a property maps to a list of IRIs, using the @coerce directive. This example was part of a discussion on how to handle complex type coercions.

```json
{
  "@coerce": {
    "authorList": [
      "@list",
      "@iri"
    ]
  }
}
```

--------------------------------

### JSON-LD Context and Value Structure

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-10-02/index.html

Illustrates specific JSON-LD structures discussed for defining contexts and handling processor pragmas. These examples highlight mechanisms for controlling data processing during compaction.

```json
{
  "@context": {
    "property": "[http://schema.org/foo"](http://schema.org/foo)
  }
}
```

```json
{
  "@value": "foo",
  "@processor": "drop-when-compacting"
}
```

--------------------------------

### JSON-LD Data Access Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-07-31/index.html

Illustrates a potential data structure for language-tagged literals and how a developer might access specific values. This example shows accessing a 'value' field from the first element of a language-specific array.

```javascript
field_name.en = [
  {'@id': 'http://example.com/node/en/foo', 'value': 'foo'},
  {'@id': 'http://example.com/node/en/blah', 'value': 'blah', 'formattedValue': 'Blah\nBlah'}
];

// Developer access example:
// data.en.value (hypothetical access)
// field_name.en[0].value
```

--------------------------------

### JSON-LD Property Generator Discussion Summary

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2012-10-02/index.html

Summarizes the core debate around property generators, `@expandAlsoTo`, and round-tripping, highlighting the need for clear consumer expectations and the trade-offs between pragmas and computation.

```APIDOC
JSON-LD Property Generators and Round-tripping:

Key Discussion Points:

1.  **Purpose of Property Generators**: To define a list of properties for which a stated term acts as a subproperty, influencing expansion.

2.  **Expansion Behavior**: When expanding, property generators can lead to the inclusion of additional properties. A flag might control this behavior.

3.  **Compaction Behavior**: During compaction, extra properties from generator expressions are typically removed unless defined elsewhere. `@expandAlsoTo` is ignored.

4.  **Round-tripping**: The ability to expand and then compact data back to its original form is a critical requirement for some use cases (e.g., Drupal export/import).

5.  **BNodes and Node-IDs**: For round-tripping and comparison, bnodes in expanded output must have stable node-IDs, requiring graph normalization.

6.  **Pragmas vs. Computation**: Using pragmas can offer a cheaper way to handle round-tripping compared to computationally intensive mechanisms like graph normalization or comparing all statements.

7.  **Ambiguity**: Throwing away IRIs within property generators is ambiguous as their origin might not be from expansion.

8.  **Consumer Demands**: Understanding consumer expectations regarding the presence of schema.org/title or other properties in expanded forms is crucial.

9.  **Semantic Annotation vs. Full IRI**: The need to communicate with multiple consumers using different vocabularies and potentially using JSON-LD instead of RDF but with full IRIs.

10. **API Direction**: Clarity is needed on whether the API is designed for round-tripping.

Related Discussion Link:
https://github.com/json-ld/json-ld.org/issues/160#issuecomment-8956476
```

--------------------------------

### JSON-LD Schema.org Context Example

Source: https://github.com/json-ld/minutes/blob/main/pre-wg/2013-04-30/index.html

An example of a JSON-LD context definition using schema.org vocabulary. This snippet illustrates how to define a default vocabulary namespace for JSON-LD documents, potentially simplifying the inclusion of schema.org terms.

```JSON-LD
{
  "@context": {
    "@vocab": "http://schema.org/"
  }
}
```