Re: JSON-LD Context

Tim, all,

(I told you I am not a JSON-LD expert!)

Your mail triggered me to look again at the JSON-LD spec, and now I understand why and how it works. I think your playground examples, ie, the way playground reacted, is indeed the way the spec should work, so it is fine, and there is no need to put the extra @vocab into the @context. Actually, agreeing with James, it may actually lead to problems. To react to your question below, I think it does matter if "motivation":"bookmarking" could be used instead of "oa:bookmarking". So: let us do the change!

As an aside to the main issue: you said:

[[[
(Although, as an aside, the current implementations I've worked with all seem to allow you to get around this by doing something like: "type" : {"@type":"@vocab", "@id": "rdf:type"} in your context. I'm not necessarily suggesting this. Mapping predicates from other namespaces not your own probably is not a great idea.)
]]]

I actually think that using this pattern may be a good idea. Yes, it is mapping a predicate from another namespace, but because it is done in the local context (both in the JSON-LD and the generic sense of the word:-) I think the advantages would supersede the disadvantages. I think the term used as "@type" was actually discussed at some earlier thread as one of the JSON-LD keywords that definitely looked ugly to pure JSON users. After all, the current @context already maps some non-OA class names like Person or Software, or predicates like "name" or "related". So yes, I think I am pretty much in favour of hiding "@type", too.

Actually… the idiom

"url"  : { "@type" : "@id", "@id" : "@id"}

also seemed to work on playground. If I then use:

{
  "@context" : {
    "type" : { "@type" : "@vocab", "@id":"rdf:type"},
    "url"  : { "@type" : "@id", "@id" : "@id"}
  },
  "type" : "http://this.type.example.org",
  "url":"http://ww.example.org"
}

Ie, if the @context is included by URI

{
  "@context" : "http://somewhere.org,
  "type" : "http://this.type.example.org",
  "url":"http://ww.example.org"
}

I get

<http://ww.example.org> <rdf:type> <http://this.type.example.org> .


Ivan

P.S. Rob, if you want, I can take care of these changes when we have an agreement; I would have to take the last steps anyway…


> On 09 Aug 2015, at 21:58 , Timothy Cole <t-cole3@illinois.edu> wrote:
> 
> Point taken.
> 
> And it terms of best practices, I take also Ivan's point that including global default @vocab IRI if you map any predicates in your context using @type=@vocab is always a good idea -- though I don't read the spec as requiring it; obviously he was involved when the spec was created and I was not.
> 
> But if we don't map oa:motivatedBy using the @type=@vocab, there's really no reason to include our Motivation terms in our context – which perhaps is one reason we left Motivation terms out of the JSON-LD context proposed in Appendix B of the FPWD of our Data Model. The trade-off is making users include a namespace prefix on all motivation values (and potentially on all values for Body/Target roles) versus reducing the explicit use of namespaces for implementers relying primarily on the oa vocabulary and less interested in the RDF aspects of the data model.
> 
> For implementers is
> 
> "motivation" : "bookmarking"
> 
> in your JSON better than
> 
> "motivation" : "oa:bookmarking"
> 
> Or does it matter not at all?
> 
> Thanks,
> Tim Cole
> 
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Sunday, August 09, 2015 2:08 PM
> To: t-cole3@illinois.edu
> Cc: Web Annotation <public-annotation@w3.org>; Ivan Herman <ivan@w3.org>; Robert Sanderson <azaroth42@gmail.com>
> Subject: RE: JSON-LD Context
> 
> Using @type=@vocab is less of an issue, yes. But even that can run into problems when working with other contexts. I'm not saying don't do it, just make sure you're aware of the potential conflicts and limitations it can impose.
> 
> On Aug 9, 2015 11:52 AM, "Timothy Cole" <t-cole3@illinois.edu> wrote:
>> Ivan,
>> 
>> I would agree with James to the extent that we probably do NOT want a GLOBALLY scoped @vocab in our context document. As he says, this can make integrating with other contexts a bit more challenging.
>> 
>> But I'm not sure that there is the same issue with using { "@type" : "@vocab", … } when mapping a single predicate (as I am suggesting for oa:motivatedBy). Doing so does not affect the @type of any subsequent mapping. James, do you have an example of a problem created by using @vocab when mapping (type coercing to @vocab) a single predicate in your own namespace?
>> 
>> At least as implemented by JSON-LD Playground and in the appspot.com RDF translator, adding a globally scoped @vocab is not needed and I was not suggesting it.
>> 
>> But in our oa context you can specify that a particular predicate in the oa namespace is of "@type" : "@vocab" rather than "@type" : "@id:" and for this predicate (and only this predicate) doing so causes the parser to look first in the active context for a matching term before assuming it needs to prepend a default namespace to make the IRI of the term.
>> 
>> So, for both the Playground and the RDF translator, this JSON-LD
>> 
>> {
>>   "@context": "http://www.w3.org/ns/anno.jsonld",
>>   "@id": "http://example.org/Anno1",
>>   "@type": "Annotation",
>>   "motivation": "bookmarking",
>>   "body" : "http://example.org/Body1",
>>   "target" : "http://example.org/Target1"
>> }
>> 
>> translates / normalizes to the following N-Triples
>> 
>> <http://example.org/Anno1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/oa#Annotation> .
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#hasTarget> <http://example.org/Target1> .
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#hasBody> "http://example.org/Body1" .
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#motivatedBy> <file:///base/data/home/apps/s%7Erdf-translator/1.380697414950152317/bookmarking> .
>> 
>> Which is NOT what is wanted.
>> 
>> However, when the @type definition of "motivation" is changed from @id to @vocab in the referenced context document or overridden (per Section 6.7 of the JSON-LD spec, duplicate context terms are overridden using a most-recently-defined-wins mechanism) as shown below
>> 
>> {
>>   "@context": ["http://www.w3.org/ns/anno.jsonld",
>>       { "motivation":   {"@type":"@vocab", "@id" : "oa:motivatedBy"} }
>>      ],
>>   "@id": "http://example.org/Anno1",
>>   "@type": "Annotation",
>>   "motivation": "bookmarking",
>>   "body" : "http://example.org/Body1",
>>   "target" : "http://example.org/Target1"
>> }
>> 
>> You get the desired N-Triples
>> 
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#hasTarget> <http://example.org/Target1> .
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#motivatedBy> <http://www.w3.org/ns/oa#bookmarking> .
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#hasBody> "http://example.org/Body1" .
>> <http://example.org/Anno1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/oa#Annotation> .
>> 
>> And defining the mapping of oa:motivatedBy does not preclude community extensions of Motivation terms. So:
>> 
>> {
>>   "@context": ["http://www.w3.org/ns/anno.jsonld",
>>       { "myNS" : "http://example.org/myNameSpace#",
>>         "motivation":   {"@type":"@vocab", "@id" : "oa:motivatedBy"},
>>         "semanticTagging": "myNS:semanticTagging" }
>>      ],
>>   "@id": "http://example.org/Anno1",
>>   "@type": "Annotation",
>>   "motivation": "semanticTagging",
>>   "body" : "http://example.org/Body1",
>>   "target" : "http://example.org/Target1"
>> }
>> 
>> Yields:
>> 
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#motivatedBy> <http://example.org/myNameSpace#semanticTagging> .
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#hasTarget> <http://example.org/Target1> .
>> <http://example.org/Anno1> <http://www.w3.org/ns/oa#hasBody> "http://example.org/Body1" .
>> <http://example.org/Anno1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/oa#Annotation> .
>> 
>> Again, as desired.
>> 
>> We should perhaps consult additional JSON-LD experts to confirm that this is the right behavior – there were several issues during the development of JSON-LD that touched on what amounted to questions about context scope and global vs. local @vocab, e.g., the Scoped Contexts Issue #247. In particular for that issue there was concern about "polluting the global context namespace with term definitions."  I am not certain I fully understood the resolution of all of these discussions. I am going by how the implementations I've tested interpret "@type" : "@vocab" when used for a single predicate. And perhaps there is some potential incompatibility when any predicate has
>> 
>> As for other classes and terms included in our context document – if they are meant to be used as the object of the @type predicate in JSON-LD instance, we seem to be okay, this is one of the advantages of using @type rather than rdf:type directly in our JSON-LD instances.
>> 
>> (Although, as an aside, the current implementations I've worked with all seem to allow you to get around this by doing something like: "type" : {"@type":"@vocab", "@id": "rdf:type"} in your context. I'm not necessarily suggesting this. Mapping predicates from other namespaces not your own probably is not a great idea.)
>> 
>> Thanks,
>> 
>> Tim Cole
>> 
>> From: James M Snell [mailto:jasnell@gmail.com]
>> Sent: Sunday, August 09, 2015 9:15 AM
>> To: t-cole3@illinois.edu
>> Cc: Ivan Herman <ivan@w3.org>; Web Annotation <public-annotation@w3.org>; Robert Sanderson <azaroth42@gmail.com>
>> Subject: RE: JSON-LD Context
>> 
>> Using @vocab essentially makes it difficult to impossible to use your context with any other context without experiencing unintended and unexpected results. I definitely recommend treading carefully.
>> 
>> -----Original Message-----
>> From: Ivan Herman [mailto:ivan@w3.org]
>> Sent: Sunday, August 09, 2015 3:34 AM
>> To: Tim Cole <t-cole3@illinois.edu>
>> Cc: Robert Sanderson <azaroth42@gmail.com>; W3C Public Annotation List <public-annotation@w3.org>
>> Subject: Re: JSON-LD Context
>> 
>> 
>> 
>> Tim,
>> 
>> 
>> 
>> you may indeed be right. As I said, my JSON-LD is fairly rusty… However, isn't it true that for this to work, we should also have a
>> 
>> 
>> 
>> "@vocab" : "http://www.w3.org/ns/oa#:,
>> 
>> 
>> 
>> set in the context file? That is what sets the "active context's vocabulary mapping", afaik.
>> 
>> 
>> 
>> Also, we should probably be consistent; the same change should be applied for all other properties where the value is one of several possible URI id-s.
>> 
>> 
>> 
>> Ivan
>> 
>> 
>> On Aug 8, 2015 10:54 AM, "Timothy Cole" <t-cole3@illinois.edu> wrote:
>>> Ivan-
>>> 
>>> I'm going off of the following paragraph from Section 6.5 of the JSON-LD 1.0 Recommendation [http://www.w3.org/TR/json-ld/#type-coercion], which says:
>>> 
>>> ***Type coercion is specified within an expanded term definition using the @type key. The value of this key expands to an IRI. Alternatively, the keywords @id or @vocab may be used as value to indicate that within the body of a JSON-LD document, a string value of a term coerced to @id or @vocab is to be interpreted as an IRI. The difference between @id and @vocab is how values are expanded to absolute IRIs. @vocab first tries to expand the value by interpreting it as term. If no matching term is found in the active context, it tries to expand it as compact IRI or absolute IRI if there's a colon in the value; otherwise, it will expand the value using the active context's vocabulary mapping, if present, or by interpreting it as relative IRI. Values coerced to @id in contrast are expanded as compact IRI or absolute IRI if a colon is present; otherwise, they are interpreted as relative IRI.***
>>> 
>>> Assuming that the Range of oa:motivatedBy is meant to include terms defined in our context document, e.g.:
>>> 
>>>     bookmarking: "oa:bookmarking"
>>> 
>>> then we should use @vocab.  This allows the correct mapping of the following line in the json-ld instance:
>>> 
>>>     "motivation": "bookmarking"
>>> 
>>> If we leave type as @id in our context document, then we are limited to using only this form in the json-ld instance:
>>> 
>>>     "motivation": "oa:bookmarking"
>>> 
>>> Note, the latter form does work correctly even if we use @vocab -- which also means that other communities can still extend our oa:Motivation ontology in their own namespaces, but the former form without the namespace prefix on the term does not.
>>> 
>>> Is there a downside to using @vocab that I am not recognizing?
>>> 
>>> Thanks,
>>> 
>>> Tim Cole
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Ivan Herman [mailto:ivan@w3.org]
>>> Sent: Friday, August 07, 2015 11:09 PM
>>> To: Tim Cole <t-cole3@illinois.edu>
>>> Cc: Robert Sanderson <azaroth42@gmail.com>; W3C Public Annotation List <public-annotation@w3.org>
>>> Subject: Re: JSON-LD Context
>>> 
>>> Tim,
>>> 
>>> I am just the messenger… and my JSON-LD is a bit rusty. But my first reaction is that what is there, ie, the first line is correct. What it says (I think) is that the value (range) of 'motivation' is a URI reference in RDF jargon, and that the property itself is oa:motivatedBy…
>>> 
>>> Ivan
>>> 
>>> > On 07 Aug 2015, at 23:39 , Timothy Cole <t-cole3@illinois.edu> wrote:
>>> >
>>> > Rob, Ivan-
>>> >
>>> > Shouldn't this line in the context document:
>>> >    "motivation":   {"@type":"@id", "@id" : "oa:motivatedBy"},
>>> >
>>> > Be this instead:
>>> >    "motivation":   {"@type":"@vocab", "@id" : "oa:motivatedBy"},
>>> >
>>> > This seems to be needed in order for motivation values without the oa: prefix to be recognized as in the oa ontology.
>>> >
>>> > Regardless, agree with Randall that it is very helpful to have this up.
>>> >
>>> > Thanks,
>>> >
>>> > -Tim Cole
>>> >
>>> >
>>> >
>>> > From: Randall Leeds [mailto:randall@bleeds.info]
>>> > Sent: Thursday, August 06, 2015 6:42 PM
>>> > To: Ivan Herman <ivan@w3.org>; Robert Sanderson <azaroth42@gmail.com>
>>> > Cc: W3C Public Annotation List <public-annotation@w3.org>
>>> > Subject: Re: JSON-LD Context
>>> >
>>> > That looks wonderful.
>>> >
>>> > On Wed, Aug 5, 2015 at 10:12 PM Ivan Herman <ivan@w3.org> wrote:
>>> >> There were some minor syntax problems that I took care of (and pushed
>>> >> on the repo); the files are now also available as
>>> >>
>>> >> http://www.w3.org/ns/anno.jsonld
>>> >>
>>> >> Ivan
>>> >>
>>> >> > On 06 Aug 2015, at 24:54 , Robert Sanderson <azaroth42@gmail.com> wrote:
>>> >> >
>>> >> >
>>> >> > A draft context, that we can put up on w3.org with Ivan's help:
>>> >> >
>>> >> >     http://w3c.github.io/web-annotation/jsonld/anno.jsonld
>>> >> >
>>> >> > Please cast an eye over it and see if there's any bugs :)
>>> >> >
>>> >> > As we haven't decided yet on the property names for the relationships, I've left them alone. I did add the classes, with some hopefully friendly names, per issues.  Also xsd, xsi, iana, and ldp from Protocol and even further issues.
>>> >> >
>>> >> > Rob
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Rob Sanderson
>>> >> > Information Standards Advocate
>>> >> > Digital Library Systems and Services Stanford, CA 94305
>>> >>
>>> >>
>>> >> ----
>>> >> Ivan Herman, W3C
>>> >> Digital Publishing Activity Lead
>>> >> Home: http://www.w3.org/People/Ivan/
>>> >> mobile: +31-641044153
>>> >> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>> >>
>>> 
>>> 
>>> ----
>>> Ivan Herman, W3C
>>> Digital Publishing Activity Lead
>>> Home: http://www.w3.org/People/Ivan/
>>> mobile: +31-641044153
>>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>> 


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