Re: JSON LD EBNF

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.

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?

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.

In Sec 8.1

'If the node object<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-node-object>
contains
the @reverse key, its value must be a JSON
object<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-json-object>
containing
members representing reverse properties. Each value of such a reverse
property must be an absolute
IRI<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-absolute-iri>,
a relative IRI<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-relative-iri>,
a compact IRI<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-compact-iri>,
a blank node identifier<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-blank-node-identifier>,
a node object<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-node-object>
or
an array<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-array>
containing
a combination of these.'

Nothing above says @reverse can have a term value.

In Sec 8.7

'The value of keys that are not
keywords<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-keyword>
 must be either an absolute
IRI<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-absolute-iri>,
a compact IRI<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-compact-iri>,
a term<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-term>,
a blank node identifier<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-blank-node-identifier>,
a keyword<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-keyword>
, null<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-null>,
or an expanded term
definition<https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#dfn-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.

-- 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