W3C home > Mailing lists > Public > public-vocabs@w3.org > February 2015

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

From: Dan Brickley <danbri@google.com>
Date: Thu, 19 Feb 2015 14:39:21 +0000
Message-ID: <CAK-qy=7vxqYsTyvTaWroktjzrvMDOx1gbrYeBrfxjw8rALuyoA@mail.gmail.com>
To: Gregg Kellogg <gregg@greggkellogg.net>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
On 17 February 2015 at 23:30, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> 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.

Which URL spec are we going by here? Lots of URLs lack path components.

e.g. 3.3 of https://tools.ietf.org/html/rfc3986 says
"If a URI contains an authority component, then the path component
   must either be empty or begin with a slash ("/") character."

Or HTTP URIs per RFC-7230 "Hypertext Transfer Protocol (HTTP/1.1):
Message Syntax and Routing" which largely defers to that work:

http://tools.ietf.org/html/rfc7230#section-2.7

"""
2.7.  Uniform Resource Identifiers

   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
   HTTP as the means for identifying resources (Section 2 of [RFC7231]).
   URI references are used to target requests, indicate redirects, and
   define relationships.

   The definitions of "URI-reference", "absolute-URI", "relative-part",
   "scheme", "authority", "port", "host", "path-abempty", "segment",
   "query", and "fragment" are adopted from the URI generic syntax.  An
   "absolute-path" rule is defined for protocol elements that can
   contain a non-empty path component.  (This rule differs slightly from
   the path-abempty rule of RFC 3986, which allows for an empty path to
   be used in references, and path-absolute rule, which does not allow
   paths that begin with "//".)  A "partial-URI" rule is defined for
   protocol elements that can contain a relative URI but not a fragment
   component.

     URI-reference = <URI-reference, see [RFC3986], Section 4.1>
     absolute-URI  = <absolute-URI, see [RFC3986], Section 4.3>
     relative-part = <relative-part, see [RFC3986], Section 4.2>
     scheme        = <scheme, see [RFC3986], Section 3.1>
     authority     = <authority, see [RFC3986], Section 3.2>
     uri-host      = <host, see [RFC3986], Section 3.2.2>
     port          = <port, see [RFC3986], Section 3.2.3>
     path-abempty  = <path-abempty, see [RFC3986], Section 3.3>
     segment       = <segment, see [RFC3986], Section 3.3>
     query         = <query, see [RFC3986], Section 3.4>
     fragment      = <fragment, see [RFC3986], Section 3.5>

     absolute-path = 1*( "/" segment )
     partial-URI   = relative-part [ "?" query ]

   Each protocol element in HTTP that allows a URI reference will
   indicate in its ABNF production whether the element allows any form
   of reference (URI-reference), only a URI in absolute form
   (absolute-URI), only the path and optional query components, or some
   combination of the above.  Unless otherwise indicated, URI references
   are parsed relative to the effective request URI (Section 5.5).
"""

As far as I can see the absolute-path construction is only used in
non-URL settings i.e. protocol headers.

My reading is that in JSON-LD 'http://schema.org' serves to identify
an URL from which a context can be acquired. We have wired up the
relevant server-side voodoo such that this works e.g. via: curl -H
"Accept: application/ld+json" http://schema.org

... where is it written that http://schema.org is a bad http URL?
(genuine question not rhetorical :)

An equal counter question: where is it written that such an url would
be dereferenced by requesting '/' ? Or is this just a convention?

Dan

ps. anyone studied HTTP2's for these issues yet?
https://tools.ietf.org/html/draft-ietf-httpbis-http2-17
Received on Thursday, 19 February 2015 14:39:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 19 February 2015 14:39:54 UTC