Re: @type:@id vs @type:@vocab

> On Mar 16, 2017, at 11:53 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Dear all,
> 
> In the 1.0 specification, in section 6.5 about type coercion it makes the distinction between:
> 
> @type:@id  -- this will expand if there's a ns:value pair, otherwise be treated as a relative URI.
> @type:@vocab -- this will expand by interpreting as a Term from the context, otherwise as above.
> 
> The playground (and other implementations) seems to not do this correctly.
> 
> For example, see:
>     http://tinyurl.com/glmagag <http://tinyurl.com/glmagag>
>  
> @id is aliased to id, with a type of @vocab.  Meaning the value "Class" should be expanded as a term, which it isn't.  Instead it's expanded as a relative URI.
> 
> @type is aliased to type, with a type of @id. Meaning that the same "Class" should be treated as a relative URI, however it treats as @vocab and looks up the term.

Aliasing of keywords only allows you to change the term you use for the keyword, not to change the way in which the values of the keyword are treated. Note the difference in the JSON-LD spec between Typed Values [1] and Aliased Keywords [2]. Keywords have special meaning in JSON-LD (aliased or not), as they are core to how the processing model works. Note that you also can’t set @container or @language on a keyword alias.

The definition of Node Objects in the Grammar section [3] describe the value requirements for keywords.

Another place to look for behavior is in the JSON-LD API algorithms, but this isn’t a reasonable place for authors to have to refer to.

Text in [3] could be improved in JSON-LD 1.1 to say “one of the following keyword[s] (or a term alias for that keyword) MUSTE be ignored when processed:”. Other descriptions could also say (or an alias), but this might be going too far.

Furthermore, we could tighten up the wording for keyword aliases in [2] to say that keyword aliases MUST be simple term definitions. Alternatively, that keys in an expanded term definition other than @id MUST be ignored, or MUST NOT be present, generating an exception. Personally, I favor requiring them to be simple term definitions. This should probably result in an exception for 1.0 processors as well, as otherwise it is silently ignored.

> Combined with framing, the aliases of id and type are not used and instead we get @id and @type despite being clearly recognized in the context, as the above (incorrect) transformations are applied.

I would think that the aliases would be used in any case for framing, and not using them sounds like an implementation bug, but we are in a territory that I think is illegal syntax in any case.

> Could someone please clarify if my understanding of the spec (6.1, 6.5) is incorrect, or if this is a bug in implementations that should be fixed. 
> 
> Many thanks!
> 
> Rob Sanderson

Gregg

[1] http://json-ld.org/spec/latest/json-ld/#typed-values
[2] http://json-ld.org/spec/latest/json-ld/#aliasing-keywords
[3] http://json-ld.org/spec/latest/json-ld/#node-objects

> -- 
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049