RE: RDF interpretation of JSON-LD with missing context

 > From: Markus Lanthaler <markus.lanthaler@gmx.net>
 > Date: Mon, 1 Jul 2013 20:22:14 +0200 To:
 > <public-linked-json@w3.org> Message-ID:
 > <017c01ce7687$ea3d46f0$beb7d4d0$@lanthaler@gmx.net>
 >
 > Removing all cc's, discussing it on the list should be enough
 >
 > On Monday, July 01, 2013 7:39 PM, David Booth wrote:
 > > 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
 > >
 > [...]
 > >
 > > Gregg responded:
 > >  > This is already covered in the JSON-LD API context
 > >  > processing algorithm in step 3.2.3:
 > >  >
 > >  > [[[ Dereference context. If context cannot be
 > >  > dereferenced, a loading remote context failed error has
 > >  > been detected and processing is aborted.  ]]]
 > >
 > > Do you really think that JSON-LD documents will be
 > > completely ignored just because the context is missing?
 > > In some cases a user may be able to get the JSON-LD
 > > author to correct the JSON-LD document or make the context
 > > available, but in other cases the user will have no way to
 > > do that, and I would imagine that in many cases the user
 > > would still like to get as much benefit from the JSON-LD
 > > document as possible.  So to my mind telling them to abort
 > > seems like turning a blind eye to the problem.  But I
 > > am really unsure of what people are likely to do in the
 > > situation of a missing context -- assuming that they still
 > > want to try to use the JSON-LD document.  Anybody know?
 >
 > The API provides a callback which can also be used to
 > recover from such errors. Hard coding it into the JSON-LD
 > algorithms would be wrong IMO. The algorithm doesn't know
 > anything about the data and so all it can do is to fail with
 > the most descriptive error message possible.
 >
 > Furthermore, it's also simple enough to provide an alternative
 > context by the API. So I think all the options you outlined
 > are already available - however, they need to be explicitly
 > requested. I believe that's the right way to address such
 > problems.

Okay, that sounds reasonable.

David

Received on Tuesday, 2 July 2013 16:13:26 UTC