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

> On 17 Mar 2017, at 00:05, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
> 
>> On Mar 16, 2017, at 1:40 PM, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com>> wrote:
>> 
>> 
>> 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]
> 
> Sorry I missed this when looking at the Annotation context. I would think you should be able to update it, though.

Yes and no.

Yes, in the sense that the context document to be downloaded is not on /TR and, indeed, an update can be made. If you guys give me a replacement, I am happy to do that.

No, in the sense that the context document is also reproduced, verbatim, in the annotation protocol rec. That cannot be changed. In other words, an erratum should be recorded in:

https://www.w3.org/annotation/errata/ <https://www.w3.org/annotation/errata/>

Pragmatically, we can do of course both, but we should put a comment into the context file that this is not identical to what is in the Rec. Oh, wait, this is JSON, it does not have comments…:-(

Ivan





> 
>> 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 <http://tinyurl.com/zw6whzk>
> 
> Great.
> 
> Gregg
> 
>> Rob
>> 
>> 
>> On Thu, Mar 16, 2017 at 12:15 PM, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
>>> On Mar 16, 2017, at 11:53 AM, Robert Sanderson <azaroth42@gmail.com <mailto: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 <http://json-ld.org/spec/latest/json-ld/#typed-values>
>> [2] http://json-ld.org/spec/latest/json-ld/#aliasing-keywords <http://json-ld.org/spec/latest/json-ld/#aliasing-keywords>
>> [3] http://json-ld.org/spec/latest/json-ld/#node-objects <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
> 


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>