W3C home > Mailing lists > Public > public-linked-json@w3.org > January 2015

Re: JSON-LD context file at schema.org - request for feedback

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 22 Jan 2015 08:23:21 -0500
Message-ID: <54C0F9C9.8010006@openlinksw.com>
To: public-linked-json@w3.org
On 1/22/15 7:00 AM, Dan Brickley wrote:
> On 21 January 2015 at 17:51, Kingsley  Idehen<kidehen@openlinksw.com>  wrote:
>> >On 1/21/15 10:38 AM, ☮ elf Pavlik ☮ wrote:
>> >
>> >On 01/21/2015 04:12 PM, Kingsley Idehen wrote:
>> >
>>> >>On 1/21/15 8:05 AM, Dan Brickley wrote:
>> >
>>>> >>>The context is content negotiable from the site homepage but also
>>>> >>>available athttp://schema.org/docs/jsonldcontext.json.txt
>> >Thanks for untangling my tangled mess of content-type names:)
> Yeah, the "ld+json" bit always throws me off balance too.
>
>> >Now when I copy and paste your example above, I get different results:
>> >
>> >curl -IH "Accept: application/ld+json"http://schema.org
>> >HTTP/1.1 405 Method Not Allowed
>> >Allow: GET
>> >Content-Type: text/plain; charset=UTF-8
>> >Content-Length: 77
>> >Date: Wed, 21 Jan 2015 17:48:04 GMT
>> >Server: Google Frontend
>> >Alternate-Protocol: 80:quic,p=0.02
>> >
>> >Here's what works:
>> >
>> >curl -iH "Accept: application/ld+json"http://schema.org
> It looks like you're trying to do an HTTP HEAD here? That isn't
> currently supported in the site implementation for Python-generated
> content, only for static files.
>
> The site is an opensource appengine Python app. Looking at
> https://cloud.google.com/appengine/docs/python/tools/webapp/requesthandlerclass#RequestHandler_head
> I suspect we could have it respond to HEAD by adding a "def head(self,
> node):" function implementation around here:
> https://github.com/schemaorg/schemaorg/blob/master/api.py
>
>>> > >Is there any chance of -I working alongside -i ?
> http://curl.haxx.se/docs/manpage.html
>
> -i, --include
>
> (HTTP) Include the HTTP-header in the output. The HTTP-header includes
> things like server-name, date of the document, HTTP-version and
> more...
>
> -I, --head
>
> (HTTP/FTP/FILE) Fetch the HTTP-header only! HTTP-servers feature the
> command HEAD which this uses to get nothing but the header of a
> document. When used on an FTP or FILE file, curl displays the file
> size and last modification time only.
>
> ... seems like implementing a "head(self, node)" function would facilitate this.
>
> I've filed an issue, although it's in the "someday" pile:
> https://github.com/schemaorg/schemaorg/issues/256
>
>> >Would it be possible for a .jsonld doc to be published, that set to content-type "application/ld+json" rather than a .txt file that currently returns content-type "text/html" ?
> I put in both versions already; the idea is that for a real context
> file, you use the homepage. For debugging, you can use the .txt
> version (text/plain). But also:
>
> curl --verbose -H "Accept: application/ld+json"
> http://schema.org/docs/jsonldcontext.json
>
> ... should do what you want.

Yes, ditto:

curl -iH "Accept: application/ld+json" 
http://schema.org/docs/jsonldcontext.json

Another nice-to-have request:

As ".jsonld" is the recommended extension in the JSON-LD spec [1], it 
would be nice if you had <http://schema.org/docs/jsonldcontext.json> 
rather than <http://schema.org/docs/jsonldcontext.json>, which will make 
life easier for those working from the spec.

We had to go through a lot of these niggling issues when adding JSON-LD 
support to DBpedia etc..


[1] http://schema.org/docs/jsonldcontext.json

-- 
Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this



Received on Thursday, 22 January 2015 13:23:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:43 UTC