W3C home > Mailing lists > Public > www-archive@w3.org > July 2013

RDF interpretation of JSON-LD with missing context

From: David Booth <david@dbooth.org>
Date: Mon, 01 Jul 2013 10:58:56 -0400
Message-ID: <51D19930.5070702@dbooth.org>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
CC: 'Pat Hayes' <phayes@ihmc.us>, 'www-archive' <www-archive@w3.org>, 'Manu Sporny' <msporny@digitalbazaar.com>, "'Hawke, Sandro'" <sandro@w3.org>, "'Wood, David'" <david@3roundstones.com>, 'David Longley' <dlongley@digitalbazaar.com>, 'Gregg Kellogg' <gregg@greggkellogg.com>
In JSON-LD, terms are converted to URIs by use of a context.  However, a 
context may be in a separate document that may not be accessible to a 
client that is attempting to interpret that JSON-LD as RDF.  Hence, the 
client may be unable to determine the full URIs corresponding to the 
JSON-LD terms, in order to generate the correct RDF model.  Since this 
is likely to be a very common problem, I think the JSON-LD spec should 
provide some constructive guidance about how a client should deal with 
this situation.

What might be some reasonable guidance?  Something along the following 
lines?

[[
If the context for a term cannot be obtained -- perhaps because the 
context document is unavailable -- then it may not be possible to 
reliably map that term to the IRI that the JSON-LD author intended.  In 
such cases, the client interpreting the JSON-LD document MAY perform a 
"best guess" mapping, with the understanding that the guess may be 
incorrect.  Suggested "best guess" techniques:

  1. If a context was previously available for an version of the JSON-LD 
document that is being processed, use that as the context.

  2. Otherwise, expand the JSON-LD terms as though they are relative 
URIs, relative to the document's base URI.
]]

Or, as a variation of #2 above perhaps a designated universal base URI
such as http://example/JSON-LD/  or http://schema.org/ .

What do others think?

Thanks,
David
Received on Monday, 1 July 2013 14:59:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:21 UTC