Re: JSON LD EBNF

Sorry for the delay in responding ...

On Dec 2, 2013, at 9:28 PM, Mark Hapner <mark.hapner@resilient-networks.com> wrote:

> Hi Gregg,
> 
> Thanks for the quick feedback. JSON LD is a great spec. It's clear that a lot of thought has gone into it. 
> 
> I'm on vacation so I'll get back to you on some points in a few days. 
> 
> On the HTTP IRI vs URI issue, it is my assumption that HTTP 1.1 only requires support for URIs. I interpreted this to mean that if a JSON LD IRI has an HTTP scheme this, by definition, restricts its value to the URI space. Possibly I've misunderstood this issue.

It's important to distinguish URLs from URI/IRIs; both may use the HTTP scheme, but IRIs are not necessarily dereferencable. That said, HTTP is being updated (see http://tools.ietf.org/wg/httpbis/), which I believe will support IRIs.

> One other JSON LD question - an extended context object can have both an @type and @container value. I'm assuming that in this case the @type is defining the type of the container element. Is this correct?

The @type indicates the datatype of the value(s) or if strings represent IRIs. @container determines how values are represented, either using an array form (@container: @set) or as an ordered list (@container: @list); @container doesn't describe the type of those values.

> On the relative IRI and blank node issues - the way the grammar rules are written there is an implication that IRI, compact IRI, relative IRI and blank node are separate terminals; and, that the rules explicitly enumerate where each is allowed. If IRI is a logical terminal that can always be one of these four forms it would be good to state this in the grammar.

It's difficult to distinguish between a compact IRI and and absolute IRI, as the prefix of a compact IRI may seem like an absolute IRI scheme. There are cases where a compact IRI cannot be used, but in practice, this means that something that might otherwise be interpreted as a compact IRI will instead to considered like an absolute IRI.

> In Sec 8.1 
> 
> 'If the node object contains the @reverse key, its value must be a JSON object containing members representing reverse properties. Each value of such a reverse property must be an absolute IRI, a relative IRI, a compact IRI, a blank node identifier, a node object or an array containing a combination of these.'
> 
> Nothing above says @reverse can have a term value.

Need to distinguish between @reverse within a context, and within the body of a document. Within a context, @reverse cannot take a term. However, within the body of a document, the object referenced by @reverse may have keys which are terms. Test expand-0043 tests this.

> In Sec 8.7
> 
> 'The value of keys that are not keywords must be either an absolute IRI, a compact IRI, a term, a blank node identifier, a keyword, null, or an expanded term definition.'
> 
> This notes the value of a term may be a keyword. It doesn't say which keywords are allowed and I didn't find any further info or examples that covered this case.

This is for establishing aliases for keywords (e.g., "id" in place of "@id"). The only keyword which cannot be aliased is @context.

Gregg

> -- Mark
> 
> 
> On Mon, Dec 2, 2013 at 4:20 PM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> 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>
> 
> 
> 
> 
> -- 
> Mark Hapner
> Consulting Engineer
> C: 408-393-8795
> O: 415-291-9600 x119
> 
>