Re: JSON LD EBNF

Gregg, thanks for the further explanation.

I'm still a bit confused on values for @id and @reverse.

Sec 8.2 does not include 'term' as an allowed value for either @id or
@reverse in a node object.

Sec 8.7 states that, in a context expanded term def, @id can have a term
value. It doesn't state the allowed values for @reverse but implies they
are the same as @id.

Based on this, it appears that @id and @reverse in a context can have a
term value; and, in a node object they cannot. Is this correct?




On Sun, Dec 8, 2013 at 12:15 PM, Gregg Kellogg <gregg@greggkellogg.net>wrote:

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


-- 
*Mark Hapner*
Consulting Engineer
C: 408-393-8795
O: 415-291-9600 x119