Re: JSON-LD onsite examples: are @context values missing a trailing slash?

> On Feb 17, 2015, at 1:34 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 
> On 2/17/15 12:53 PM, Gregg Kellogg wrote:
>>> On Feb 17, 2015, at 8:12 AM, Niklas Lindström <lindstream@gmail.com <mailto:lindstream@gmail.com>> wrote:
>>> 
>>> 
>>> On Tue, Feb 17, 2015 at 4:20 PM, Jarno van Driel <jarnovandriel@gmail.com <mailto:jarnovandriel@gmail.com>> wrote:
>>> I noticed that the @context value in the JSON-LD examples on schema.org <http://schema.org/>'s site are noted as:
>>> 
>>> "@context": "http://schema.org <http://schema.org/>",
>>> 
>>> Where "http://schema.org <http://schema.org/>" doesn't contain a trailing slash.
>>> 
>>> Yet when I look at the official specs (http://www.w3.org/TR/json-ld/ <http://www.w3.org/TR/json-ld/>) I see all values do contain a trailing slash, eg:
>>> 
>>> "@context": {
>>>     "@vocab": "http://schema.org/ <http://schema.org/>"
>>> }
>>> 
>>> Now to me it seems that urls without a trailing slash would resolve in urls like for example schema.orgArticle as opposed to schema.org/Article <http://schema.org/Article>, which makes me wonder whether or not the slash matters for the @context.
>>> 
>>> Any thoughts?
>>> 
>>> The difference is that a @context value (if it is a string) represents a URL to a context definition. This is mechanically dereferenced before anything is interpreted. The @vocab value on the other hand, is used syntactically to construct URIs by concatenating it with local terms (as you describe).
>> 
>> Exactly. Some sites will force a redirect if the URL does not end in a "/", but schema.org <http://schema.org/> does not, so in this case it doesn't really matter. For other uses, this could result in a redirect, but a conforming JSON-LD processor will handle this transparently.
>> 
>> Gregg
>> 
> 
> Gregg,
> 
> This heuristic needs some clear emphasis in the JSON-LD specs related docs, if that isn't the case already.
>  
> "@context": "http://schema.org <http://schema.org/>" isn't good practice, having users depend on processors to support such a heuristic (consistently) will be problematic. 
> 
> Does it really hurt anyone to state:
> 
> "@context": "http://schema.org <http://schema.org/>/" ? 

This isn't a JSON-LD heuristic, but a general web server mechanism to handle ill-formed URLs. As it happens, although it's common practice, http://schema.org is not a valid URL, as it doesn't have a path component. However, it's common practice for web servers to handle such URLs by normalizing them, in this case, by adding a trailing '/'. Some servers do this by redirecting the agent to the proper resource, it seems that schema.org simply returns the expected resource.

JSON-LD simply follows redirects when requesting resources, as most any other HTTP agent would do (such as a web browser).

Of course, it's always good practice to use well-formed URLs, which means that "@context": "http://schema.org/" is correct, but practice shows that this doesn't end up mattering.

The JSON-LD API does not call this out specifically, as that's part of HTTP, although there is a brief mention of recording the eventual redirected URL due to redirects [1]. There are numerous tests on handling remote documents that JSON-LD processors must pass to be considered conformant.

[1] http://www.w3.org/TR/json-ld-api/#remote-document-and-context-retrieval
> -- 
> Regards,
> 
> Kingsley Idehen       
> Founder & CEO 
> OpenLink Software     
> Company Web: http://www.openlinksw.com <http://www.openlinksw.com/>
> Personal Weblog 1: http://kidehen.blogspot.com <http://kidehen.blogspot.com/>
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen <http://www.openlinksw.com/blog/~kidehen>
> Twitter Profile: https://twitter.com/kidehen <https://twitter.com/kidehen>
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about <https://plus.google.com/+KingsleyIdehen/about>
> LinkedIn Profile: http://www.linkedin.com/in/kidehen <http://www.linkedin.com/in/kidehen>
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this <http://kingsley.idehen.net/dataspace/person/kidehen#this>