- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 22 Jan 2015 08:23:21 -0500
- To: public-linked-json@w3.org
- Message-ID: <54C0F9C9.8010006@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 22 January 2015 13:23:48 UTC