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

On Fri, Mar 17, 2017 at 10:06 AM, Ivan Herman <ivan@w3.org> wrote:

>
> On 17 Mar 2017, at 00:05, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>
> On Mar 16, 2017, at 1:40 PM, Robert Sanderson <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/
>
> 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…:-(
>

Well, it is JSON-LD, so you do have rdfs:comment. ;)

By which I mean that since JSON-LD contexts allow data to be put in them,
you could add e.g.:

    {
      "@context": {...},
      "http://www.w3.org/2000/01/rdf-schema#comment": "Note that this is
not identical to what's in the rec."
    }

(Alongside all kinds of other structured information, such as dc:version,
links to specs, errata and whatnot.)

Cheers,
Niklas



> 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
>
>
> Great.
>
> Gregg
>
> 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
>
>
>
>
> ----
> Ivan Herman, W3C
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153 <+31%206%2041044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>