Make sure you have a good headset with a microphone as any background noise is distracting to others during the call. If there is excessive noise on your connection, you will be muted until you need to speak. Make sure you join the IRC channel as links and code examples are usually shared over the chat channel.

Text and Audio Logs

The public JSON-LD teleconferences and all of the decisions made in those meetings are listed below. Click on each link to take you to the full text and audio log of the meeting:

Support conversion of lists of lists to list objects by preserving the blank node head of the inner list. This resolves feature-at-risk #4 in the JSON-LD API specification. [permalink]

Make an editorial update to the JSON-LD specification to clarify that the @type keyword is context sensitive and make its various usages more clear in the specification. This addresses issue at risk marker #9 in the JSON-LD syntax specification. [permalink]

Keep the @base: null feature in the JSON-LD specification as it is defined in the Candidate Recommendation specification. [permalink]

When processing free-floating nodes, if there is an @index keyword in the node, it is not a free-floating node. [permalink]

The Candidate Recommendation period for JSON-LD is closed as of October 15th 2013. [permalink]

JSON-LD 1.0 and the API will remain in Candidate Rec for an additional week to fix a bug in the spec related to the useRdfType flag and add an additional test. After the spec text has been fixed, and a test created, implementers will be required to file new implementation reports. Once they have done so, the specs will exit CR. [permalink]

Interpret objects that do not have a @context entry as the JSON-LD Context when passed into the API functions (via any context parameter). When passing in an array of objects and strings, the same rule applies. Remote context documents specified via a URL are still required to contain an @context key to be a valid JSON-LD Context. [permalink]

RDF WG issue 129, 130, 132, 133, 134, and 135 have been addressed by the group and are resolved. Manu will send out official responses. [permalink]

The JSON-LD test suite will be a living test suite (updated as needed). The version of the test suite when we transition into Candidate Recommendation will be assigned a git tag, so that others can test and report against a static version of the test suite. [permalink]

Make it clear in the specification that objects can be provided to the context parameter can either be JSON-LD Contexts, or objects containing JSON-LD Contexts. [permalink]

The JSON-LD API should process all documents labeled with media types using the application/json or any media type with a +json suffix. Implementations must not follow an HTTP Link Header if you encounter an application/ld+json media type. [permalink]

Convert normative appendices A, B, and C to normal normative sections, leaving them at the same location in the document. [permalink]

Fix a bug in the flattening and fromRDF algorithm by not promoting undescribed nodes or datatypes to subjects during the flattening/fromRDF algorithms. [permalink]

Graphs are not free-floating nodes and should not be removed during the flattening or fromRDF algorithm. [permalink]

Add an option to produce "extended RDF", which defaults to false. If the option is true, "extended RDF" will be produced, retaining triples that have blank nodes as predicates. If the option is false, standard RDF will be produced and triples with blank node properties will be discarded. [permalink]

When mapping properties, if the author is not yet ready to commit to a stable IRI, suggest mapping the property to an IRI that is documented as unstable. [permalink]

Link all Basic concept sections to the Advanced Concepts section to ensure that readers understand that there are more advanced concepts associated with the basic features of JSON-LD. [permalink]

Adopt proposal 2g and replace the first paragraph in the JSON-LD Syntax Introduction with: Linked Data[LINKED_DATA] is a way to create a network of standards-based machine interpretable data across different documents and Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web. [permalink]

In the security considerations section, reference RFC4627 and add text explaining that evaluating the data as code can lead to unexpected side effects compromising the security of a system. [permalink]

Add the following text to the Security Considerations section: When processing JSON-LD documents, links to remote contexts are typically followed automatically, resulting in the transfer of files without the explicit request of the user for each one. If remote contexts are served by third parties, it may allow them to gather usage patterns or similar information leading to privacy concerns. Explain that this can be controlled through effective use of the API. [permalink]

Remove the @type restriction for reverse properties. This also means that a reverse property won't be implicitly type-coerced to @id anymore. [permalink]

Add the following normative text to the JSON-LD Syntax specification: The normative algorithm for interpreting JSON-LD as RDF is specified in the JSON-LD Processing Algorithms and API specification [JSON-LD-API]. [permalink]

Make David Booth's bullet-point addition to the JSON-LD Syntax spec: " * Software developers who want to generate or consume Linked Data, an RDF graph or an RDF Dataset in a JSON syntax." [permalink]

Add spec text to the following effect into the JSON-LD Syntax specification: JSON-LD was designed to be usable directly as JSON, with no knowledge of RDF, but was designed also to be usable as RDF (if desired), for use with other Semantic Web technologies like SPARQL. People intending to use JSON-LD with RDF tools will find it can be used as another RDF syntax, like Turtle. Complete details of how JSON-LD relates to RDF are in Appendix C. [permalink]

Make other editorial changes as needed to avoid implying that JSON-LD is not necessarily RDF. [permalink]

Add spec text to JSON-LD Syntax. Appendix C: JSON-LD is a _concrete RDF syntax_ as described in [RDF11_CONCEPTS]. Hence, a JSON-LD document is both an RDF document and a JSON document and correspondingly represents both an instance of the RDF data model and an instance of the JSON-LD data model. [permalink]

The default value of the useNativeTypes flag should be set to 'false' in the JSON-LD API. [permalink]

Add explanatory text to the JSON-LD API specification explaining the risks of the useNativeTypes flag and how to do proper conversion to/from native types using the to/from RDF method call. [permalink]

Add issue markers to the 2nd Last Call for JSON-LD Algorithms and API to warn about how the useNativeTypes flag and algorithm might change, and to also warn about the details of referencing the DOM-WHATWG spec wrt. Futures may change. [permalink]

When compacting IRIs @vocab should take precedence over Compact IRIs. This reverses the previous order of precedence. [permalink]

Specify what canonical lexical form is for xsd:integer and xsd:double by referencing the XML Schema 1.1 Datatypes specification. When processors are generating output, they are required to use this form. [permalink]

Publish the JSON-LD Syntax and Algorithms specifications as Final Community Group Specifications (FCGS) and prep the RDF WG Last Call (LC) documents for publication on April 4th 2013. [permalink]

The term selection algorithm should use the '@null' token to specify the null value and the '@none' token to specify the none value. [permalink]

Do not drop empty arrays (sets) and empty lists in expansion and compaction. [permalink]

Remove blank node re-labeling during expansion since it is no longer required. The flattening algorithm must still re-label blank nodes. [permalink]

Change 'optimize' flag to be a 'processingMode' option. The default value for JSON-LD 1.0 processors is 'json-ld-1.0'. Implementers may accept other values, but must ensure that those values are not prefixed with the string 'json-ld'. If the processingMode is set to 'json-ld-1.0', the outcome must be the same as the algorithms. [permalink]

Add the JSON-LD in HTML feature to the JSON-LD Syntax specification without support for @data-context. We are still discussing @data-context and the danger of it forcing a JSON-LD initial context. [permalink]

Remove Property Generators from JSON-LD before Last Call due to no developers needing the feature, the feature having a high potential of misuse, and because of the complexity it adds to the specification. [permalink]

'base' (passed in via the API) sets the document base, @base (in the document) overrides any value set by 'base' (passed in via the API). [permalink]

Allow @base to be set to the empty string. If @base is set to the empty string, relative IRIs are processed according to RFC 3986 Section 5.2.2 (which is how they're always processed in JSON-LD). [permalink]

Support @base and @language declarations in the @context. Warn developers that JSON-LD contexts that are to be used as remote contexts probably shouldn't include @language or @base. [permalink]

JSON-LD will continue to support blank node identifiers for properties and graph names. When converting data to RDF 1.1, the specification will not introduce any special checks to handle these specific cases. It is up to the implementations to figure out how to convert this data to something conformant to RDF 1.1. [permalink]

This group re-affirms that the common practice when naming a graph is to use either an IRI or a blank node identifier. The JSON-LD specification remains unchanged. When expressing graphs in Linked Data, the graph name SHOULD be an IRI. [permalink]

Publish the JSON-LD 1.0 syntax specification as of February 19th 2013 as a Final Community Group Specification. [permalink]

Base future JSON-LD Algorithms 1.0 specification work on Dave Longley's alternate2.html specification, keeping in mind that the group is not suggesting that all algorithms are finalized. Algorithms will need to be clarified further after the base document is picked. [permalink]

Add a JsonLdUrlDereferencer option to the JSON-LD API calls. It can be a function that takes a URL and a callback, and calls the callback with an error or the result of dereferencing that URL. If the option is provided, then the implementation MUST use it to dereference remote contexts. [permalink]

If "@type": "@vocab" is specified for a term in the active context, then processing for the value associated with the term attempts to resolve it as an IRI - first processing it as a term, then a CURIE, then an absolute IRI, then against the active @vocab (if present), then a document-relative IRI. [permalink]

Include the text "Throughout this specification, the term 'URL' means IRI as defined in RFC3987. The reason we use URL is because it is more familiar to Web developers." and use the term URL everywhere in both specifications. [permalink]

JSON-LD Processors do not modify URLs other than to translate between relative and absolute URLs. Specifically, they do not implement the URL processing rules as outlined in the HTML5 specification. [permalink]

Disallow free-floating values and IRIs in the JSON-LD Data model. If a free-floating value/IRI is detected during expansion, drop the value/IRI. [permalink]

JSON-LD Processors MAY issue validation warnings for malformed IRIs and BCP47 language strings, but they MUST NOT attempt to correct validation errors. [permalink]

Add a .flatten() method to the JSON-LD API, which returns all data in flattened, compact form. Remove the flatten flag from the .expand() and .compact() methods. Ensure that the .flatten() method preserves data in named graphs. [permalink]

Remove the .toRDF() and .fromRDF() WebIDL API calls into a separate document that will not be a part of the JSON-LD 1.0 work. The to/from RDF algorithms will still be a part of the JSON-LD API 1.0 work. [permalink]

Add a note to the "Relationship to RDF" section to specify that if clients that do not understand Datasets are to be supported using JSON-LD, that the primary information should go in the default graph. [permalink]

Keep values of @graph that are arrays consisting of just one element as arrays. [permalink]

Do not compact "node references" that are values of @graph to strings. [permalink]

The JSON-LD API specification will define two products: 1) A JSON-LD Implementation, and 2) A JSON-LD Processor, which is dependent on a valid JSON-LD Implementation and implements the asynchronous API. [permalink]

Simplify the error handling mechanism by passing an error object to the callbacks which only consists of an error code and an optional error message containing additional information for debugging. [permalink]

State in the syntax spec that JSON-LD can be used as a RDF graph source. A consumer would just use the default graph and ignore all named graphs in that case. This would allow a server to use, e.g., both Turtle and JSON-LD in content negotiation. [permalink]

Close ISSUE-159 by referencing ISSUE-133: no further actions required. [permalink]

Clarify why the @set keyword exists in the JSON-LD Syntax specification. Namely, it exists if developers want to selectively ensure that a term's values will always be compacted to an array in compacted form. For the avoidance of doubt, @set is allowed in the body of a JSON-LD document and the spec should explain it's use within the @context and the body of the document. [permalink]

Normatively define the concept of a JSON-LD Dataset. In the context of a Dataset, a JSON-LD document including only a default graph serializes a Dataset with only a default graph. A JSON-LD document describing a default graph and/or one or more named graphs serializes a Dataset with default and named graphs. [permalink]

Normatively define the concept of a "JSON-LD document", including description of the scope of blank nodes, which is the scope of the document. [permalink]

Add in the RDF-mapping section Richard is writing a statement that JSON-LD documents serialize datasets (which may contain only a default graph) [permalink]

Align with RDF WG ISSUE-105 (once there is a final decision from the RDF WG) regarding graphs, datasets, authoritative representations, and content negotiation. [permalink]

The rel=http://www.w3.org/ns/json-ld#context relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document. [permalink]

Defer creation of a .graphify() mechanism until after JSON-LD 1.0. [permalink]

Place the Algorithms section in the JSON-LD API document before the API section. Make the API section normative, but clarify that implementers MAY provide their own API that is compliant with the Algorithms. [permalink]

State in the definition of each applicable algorithm that the input is a (well-formed) JSON-LD document. State in the conformance section of theAPI/Algorithms/Proce ssing document that the spec does not constrain the behaviour of JSON-LD processors for JSON documents that are not (well-formed) JSON-LD documents. [permalink]

Define "JSON-LD processor" in a Conformance section in the JSON-LD API. [permalink]

Push the addition of '@container': '@graph' to the JSON-LD Syntax specification off to a later version of JSON-LD. [permalink]

Allow a term to be mapped to null (either directly or by setting @id to null). This mapping is stored in the active context and also overwrites a @vocab mapping meaning that the term does not expand to an IRI and will thus be dropped when expanding. [permalink]

Remove the term node reference as it is not needed; one term (currently node definition) is sufficient. [permalink]

Rename node definition to node object because 1. it doesn't actually “define” a node, and 2. to make more explicit that it is a kind of JSON object [permalink]

Add a statement in the introduction of the JSON-LD syntax specification saying that JSON-LD is a serialization of the RDF data model. [permalink]

Add the following statements to the specs: a) "Authors SHOULD NOT use unconnected nodes (a node definition that does not contain any properties) in JSON-LD documents." b) "Authors SHOULD NOT use blank nodes as edge labels." c) "JSON-LD processors MUST normalize all language tags to lowercase when processing documents via the JSON-LD Algorithms." d) "Blank node labels are scoped to the JSON-LD document." [permalink]

Do not support constructs like "@type":{"@id":"A"} in the spec as that would suggest to developers that they could include other properties of the type there as well. [permalink]

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. [permalink]

Move the optional expansion context parameter in the .expand() call into the last JsonLdOptions parameter. [permalink]

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. [permalink]

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. [permalink]

Table issue-140 for the time being, delay discussion until all other issues for JSON-LD 1.0 have been addressed. [permalink]

Adopt Gregg Kellogg's property generator algorithm when expanding/compacting with the following modifications; 1) use node definitions everywhere when expanding, 2) generate bnode IDs for all node definitions without an '@id', 3) use deep comparisons when eliminating node definitions during compaction. [permalink]

Add warning language to the JSON-LD Syntax and API specs noting the most problematic issues when working with property generators. [permalink]

Add a non-normative note to tell implementers that their implementations may have a feature that allows all but one node definition created by a property generator to be collapsed into a node reference. [permalink]

Do not support id-maps via 'container'; '@id' in JSON-LD 1.0. [permalink]

Rewrite the introductory portions of the JSON-LD document to explain JSON-LD in JSON terms first, then describe the advantages of JSON-LD, then rework the Linked Data section as the JSON-LD data model section. [permalink]

Support a 'flatten' option to .expand() and .compact(). The value of the option will be the graph to flatten and return. The default value will be false, to ensure that that the JSON-LD input document is not flattened. [permalink]

Continue to support 'useNativeDatatypes' in .fromRDF(), specifying how the native type conversion happens. Do not support options for overriding each native datatype with a different value. [permalink]

Do not support a pre-processing step option in the JSON-LD API to transform incoming JSON. [permalink]

Do not support a declarative mechanism that is capable of mapping array position to an RDF property. [permalink]

The JSON-LD API method signatures across all languages are exactly the same. If a developer wants synchronous behavior, they MUST NOT add the callback parameter. Add an issue marker to the JSON-LD API spec stating that this functionality is at risk. [permalink]

Add support for language maps via the "@container": "@language" annotation in @context. For example: "tags": { "@id": "http://example.com/vocab#tags", "@container": "@language"}. The value of the term MUST be an associative array. All associative array keys MUST be BCP47 language strings. [permalink]

JSON-LD will support a JSON-LD Processor Event mechanism that will report certain events (to be decided later) via a callback given through JSON-LD API calls. [permalink]

The JSON-LD Processor Event callback would be registered for every JSON-LD API call, and would provide the type of event and the data associated with the event for the callback. This mechanism would be used to report potential errors, warnings and when the processing of the document was complete. [permalink]

When a JSON-LD processor processes input that would result in an exception, it should instead call the JSON-LD Processor Event callback with data concerning the issue that was detected. [permalink]

Do not support the @extension keyword at this point in time. [permalink]

In general, for expansion, ensure that all property values are expressed in expanded value form (e.g. {"@value": 5}, {"@value": "foo"}, {"@id": "http://example.com/"}) with the exception of @id and @type. [permalink]

In expanded form, @graph must be expressed in expanded value form (e.g. "@graph": [{"@id": "http://example.com/foo#graph}]) [permalink]

In general, if the author's intent is clear, we should transform the input into proper JSON-LD (keeping the processor mode, if any, in mind - in strict mode, throw exceptions, in lax mode, attempt to interpret the value). [permalink]

When converting toRDF(), any value that is a JSON number that has a fractional value MUST be treated as an xsd:double using the printf("%1.15E", number) representation. [permalink]

There are no mandatory options in the JSON-LD API. Defaults must be specified for all options passed to JSON-LD API methods. [permalink]

The default for the base IRI for JSON-LD API methods is the current document IRI if in a browser context, or the empty string if there is no document context. [permalink]

The result of framing MUST be an object with a @context and @graph property. The value of @graph is always an array containing zero or more results. [permalink]

For framing, use a combination of @preserve and @null, which are replaced in post-processing to avoid the problem of them disappearing during expansion or compaction. [permalink]

If JSON-LD has an initial context, it MUST be specified external to the JSON-LD Syntax specification at a well-known location. [permalink]

In JSON-LD a fragment identifier MAY identify a node in the linked data graph expressed in the document. This idiom, which is also used in RDF [RDF-CONCEPTS], gives a simple way to "mint" new, document-local IRIs to label nodes and therefore contributes considerably to the expressive power of JSON-LD. [permalink]

When round-tripping xsd:boolean values from JSON-LD through expansion and back through compaction, a JSON-native boolean value with xsd:boolean datatype coersion will remain a JSON-native boolean value. [permalink]

During expansion, a native JSON value with type coercion applied gets expanded to the expanded object form where the value of @value is still in the native JSON form and @type is the type in the type coercion rule. [permalink]

When compacting, if there is a direct match for @type for the property and @type for the property in the context, then the value of the property is replaced with the value of @value. [permalink]

Introduce a 'useNativeTypes' flag for the fromRDF algorithm which, when set, attempts to convert xsd:boolean, xsd:integer, and xsd:double to native JSON values. If the conversion fails the value will be converted to the expanded object notation form. [permalink]

Adopt the 6 points in ISSUE-106 along with Gregg and Longley's proposal for @graph processing in framing as the way we approach named graph support in JSON-LD. [permalink]

JSON-LD keywords MUST NOT be re-defined in the @context. If a JSON-LD processor detects that a JSON-LD keyword is being re-defined, it MUST throw an exception. [permalink]

Do not re-introduce typing JSON-LD @value via something like @datatype or @valuetype. [permalink]

If the result of IRI compaction has an @container @list and there are multiple @list values, throw an exception. When doing IRI compaction do not select terms (other than absolute IRIs) that have @container @list if the value has more than one list. [permalink]

JSON-LD allows sets of lists except where it conflicts with the previous resolution. [permalink]

Add an option to the fromRDF algorithm to skip step 5.6 "If the property is rdf:type use @type" to support the use of a term in place of the @type keyword during conversion from RDF to JSON-LD. [permalink]

When performing expansion properties that are coerced to a @container type of @list MUST be placed in an array in expanded form. For example, "prop-iri": [{"@list": [1, 2]}] is correct, "prop-iri": {"@list": [1, 2]} is not. [permalink]

Re-affirm that the aliasing of @context is disallowed due to algorithmic complexity/ambiguity and lack of a compelling use case. [permalink]

A @context is processed without regard to keyword aliases. Keyword aliases are taken into account when processing the body of a JSON-LD document. [permalink]

If @graph is the only property in the document's top level object, it MUST be dropped in expansion and compaction. In all other cases (which includes @graph at the document's top level object when there are other properties other than @context at the same level), @graph MUST NOT be dropped in expansion and compaction. [permalink]

The first input parameter for all JSON-LD API methods MAY be an object, an array of objects, or an IRI (DOMString). [permalink]

The second input parameter to the .compact() method is the context that should be used for compaction. The value can be either an object or an IRI. [permalink]

The second input parameter to the .frame() method is the frame that should be used for compaction. The value can be either an object or an IRI. [permalink]

If the optimize flag is not set, the context used for compaction MUST be included without modifications in the resulting document. This applies to both context objects as well as contexts specified by passing an IRI. If the optimize flag is set, a processor is free to modify the context in order to optimize the resulting document body. [permalink]

Remove the normalization algorithm and API from the JSON-LD API specification. The normalization algorithm will be placed into a separate RDF Graph Normalization specification which contains an API for retrieving a set of normalized statements. [permalink]

Using "@list" and "@set" as keys in JSON-LD values that are expressed in expanded form is allowed. [permalink]

During compaction "@set" expressed in expanded form MUST be optimized away if it is not coerced to a "@list". During expansion "@set" MUST be optimized away. [permalink]

The use of "@container" is ignored in the body of a JSON-LD document. [permalink]

The value of the @value key is always transformed to a string by the JSON-LD processor. [permalink]

Unless there are type coercion rules in the @context that apply, native JSON numbers and strings are not modified in compacted or expanded form. [permalink]

Support the use of @language in term definitions to specify the associated @language for the term. If both @type and @language are specified, @language is ignored. [permalink]

If @language is specified at the top-level of a @context, then it applies to all native strings that would be interpreted as plain literals in the JSON-LD body. The @language can be overridden in term definitions by specifying a different @language value, including @language: null, or by specifying a @type for the term. [permalink]

Do not support the direct naming of lists using IRIs in this revision of JSON-LD. [permalink]

Convert all values coerced to xsd:double to strings using the C-syntax formula of "%1.16e". [permalink]

Unless otherwise specified, when 'null' is used in the @context, it removes any definition associated with the key. [permalink]

If @context is set to 'null', then the active context is cleared or set to the initial context (depending on the resolution to ISSUE-80) [permalink]

Unless otherwise specified, if 'null' is associated with a key in the body of a JSON-LD document, then the JSON-LD processor MUST act as if the key-value pair was never declared. If @value or @list is set to null in expanded form, then the entire JSON object is ignored. [permalink]

If an empty array ([]) used as a value is not subject to @list coercion, then the value MUST be removed from normalized output. The empty array MUST be preserved in compacted and expanded output. [permalink]

When normalizing, anything that is not coerced to a @list container type that has an empty array for its value is removed from the normalized output. [permalink]

When compacting and expanding, anything that is coerced to a @set or a @list container type that has an empty array for its value is preserved in the compacted and expanded output. [permalink]

Unless otherwise specified, when performing the expansion algorithm all values must be contained in a JSON array structure. This does not apply to values for syntactic keys such as @value, @language, @id, and @type when used to specify a datatype. [permalink]

When compacting, anything that is coerced to a @set or a @list container type has its values put into an array in the compacted output, even if there is only one value. [permalink]

For non-JSON-LD values in @context, in general, they are ignored by JSON-LD processors. When compacting, the non-JSON-LD values can be removed. When expanding, the entire @context is removed and thus the non-JSON-LD values are removed. [permalink]

Override part of the decision made in ISSUE-56 - When performing expansion, non-JSON-LD values are not dropped from the document, but are ignored. [permalink]

The @graph keyword is used to express a collection of one or more JSON objects (to express a graph which may or may not be fully connected) [permalink]

If a key in a JSON-LD document contains a colon, it is a CompactIRI if the prefix is defined as a term in the active context, otherwise it is an AbsoluteIRI. The only exception to this rule is if "//" follows the first colon, and in that case, the value is an AbsoluteIRI. [permalink]

If a key in a JSON-LD document contains a colon and the first colon is not followed by "//", it is a CompactIRI if the prefix is defined as a term in the active context, otherwise it is an AbsoluteIRI. [permalink]

When processing keys in a JSON-LD document, ignore keys and do not process the subtree for keys that do not have a mapping in the @context. When compacting and expanding, drop keys that do not have mappings from the output. [permalink]

Mapping a key to _null_ removes a mapping for that key active context [permalink]

A term can only be redefined, never partially reconfigured [permalink]