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

Ahh, thank you Gregg!

The relevant bits from 6.2 (in 1.1) or 8.2 (in 1.0):

> If the node object contains the @id key, its value must be an absolute
IRI, a relative IRI, or a compact IRI (including blank node identifiers).
> If the node object contains the @type key, its value must be either an
absolute IRI, a relative IRI, a compact IRI (including blank node
identifiers), a term defined in the active context expanding into an
absolute IRI, or an array of any of these

So @id is explicitly like @id, and @type is explicitly like @vocab.
I note that the W3C Annotation context is thus wrong, as is IIIF with the
same culprit being responsible for both. [me]

Framing wise, with a real context document that just aliases rather than
tries to redefine the processing, it works as expected.  Demonstrated in:
http://tinyurl.com/zw6whzk

Rob


On Thu, Mar 16, 2017 at 12:15 PM, Gregg Kellogg <gregg@greggkellogg.net>
wrote:

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


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