Re: JSON LD EBNF

Thanks Mark! This is quite useful. I actually have my own EBNF Parser (http://rubygems.org/gems/ebnf), which could likely parse this grammar and create a parser generator for it, assuming that it is LL(1). Having an EBNF grammar for JSON-LD could enable streaming JSON-LD parsers, which aren't dependent on reading an entire document into memory before parsing, as typically is the case when using standard JSON libraries.

I'm not sure i follow your question about HTTP not supporting IRIs. IRIs are typically described using an HTTP scheme. For reslovable IRIs, these are really described as URLs e.g., in HTML 5.

Issue - There are a number of places where the spec does not explicitly support the use of a relative uri  where it supports the other forms of resolvable uri
- Everyplace an IRI is found, it can be a relativeIRI. In most cases, processing rules require that these resolve to absolute IRIs, typically relative to a document location or @base declaration.

Issue - The spec notes that a keyword can be a value of a term; however, it does not specify which keywords are allowed
- The only place where a keyword can be the value of a term is within a context definition, which is for the purpose of creating an alias. For example {"id": "@id"} within a context definition defines "id" to be an alias for @id. There are other places within a context definition where a keyword is on the RHS, for instance @container: @list or @type: @id. I can't think of any cases where a keyword is on the RHS of a property outside of a context definition.

Issue - The spec implies that the list of possible values of an expanded term def @reverse and @id are the same;  however, this is not explicitly stated
- It is defined specifically in the API spec.

An @base value may be a relative uri. This implies a 'local' @base can be derived from an 'outer scope'  @base. The spec does not explain this semantic.
- Defined in the API spec; it can also be from the document location.

Issue - How is a context object @vocab blank node value used?
- There's not a good reason to using a blank node for the value of an @vocab, but the algorithms in the API define how expansion should work; at least the test-suite includes tests for this.

Issue - The spec does not include a term as a valid node object @reverse value - this seems to be an error
- Can you provide a spec reference for this?

Issue - A node term value, @list value and @set value may be a string but it is not noted that the string may  be a form of string that JSON LD will resolve to a uri.
- Term values, including those that are @list or @set can resolve to either scalar values (literals), BNodes or IRIs. If the term is defined to have @type: @id, then the normal relative IRI resolution algorithms define how a string is turned into an IRI (or bnode).

Issue - The spec grammer does not allow a node object @id value to be a term. This seems to be an error. Ditto
- This is intentional; previously the grammar did allow these to be terms; to avoid relative IRIs from being resolved against @vocab accidentally.

Issue - The spec grammar does not allow a node object key to be a blank node; however, elsewhere it states  that node object keys can be blank nodes and that this allows JSON LD to support nodes that cannot be represented in RDF
- Can you provide a spec reference where it says that an object key can't be a BNode? 8.2 says it can be a compact IRI, and a BNode is effectively treated like a compact IRI.

Note W3C EBNF uses a production number in front of each rule, for example:

[1] jld-context-object ::= '{' jld-context-pair (',' jld-context-pair)* '}'

It's just informative, but it's part of the EBNF definition from [1]. My own EBNF for EBNF is at [2]

Gregg Kellogg
gregg@greggkellogg.net

[1] http://www.w3.org/TR/REC-xml/#sec-notation
[2] https://github.com/gkellogg/ebnf/blob/master/etc/ebnf.ebnf

On Nov 30, 2013, at 2:13 PM, Mark Hapner <mark.hapner@resilient-networks.com> wrote:

> Here is a draft of JSON LD EBNF I created and an EBNF railroad track diagram generated for it with http://bottlecaps.de/rr/ui. 
> 
> The ENBNF file lists a few minor grammar issues I came across in its comments. If someone would let me know the resolution of these and/or any issues with the EBNF I would appreciate it.
> 
> -- 
> Mark Hapner
> Consulting Engineer
> C: 408-393-8795
> O: 415-291-9600 x119
> 
> 
> <json-ld.ebnf><jld-diagram.xhtml>