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

RE: Specify how terms are treated when they are not specified in the context (ISSUE-56)

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Fri, 13 Jan 2012 23:47:49 +0800
To: <public-linked-json@w3.org>
Message-ID: <00f801ccd20a$b6ab7e60$24027b20$@lanthaler@gmx.net>
On Friday, January 13, 2012 2:14 AM, Gregg Kellog wrote:
> In the case of {"data": "foo"}, even if "data" isn't mapped, it is a
> valid relative IRI, so if the document was loaded from
> http://example.com/doc/, it would expand to
> http://example.com/doc/data. This is also common practice in languages
> such as Turtle, where it is common to use relative IRIs.

I understand that, but I wouldn't like to have that behavior in JSON-LD as
it makes it impossible to just "annotate" parts of a JSON document.


> This doesn't address IRI expansion for properties, but we pulled back
> from having specialized IRI processing based on the position, and I
> don't think we should start now.

This is not required. See below.


> [...]
> 
> I think the way to deal with this is to define that an IRI mapping to
> _null_ explicitly causes that value (and all descendant nodes) to be
> ignored. We can add to the initial context that "@comment" is mapped to
> _null_.

Also this is not required if we change how relative IRIs have to be written.
See David's comment in ISSUE-56:

"We need a way to unambiguously distinguish between IRIs/terms and regular
JSON keys. We can't just rely on IRIs/terms not being present in the
context. As Markus suggests, issue #49 option 2 would enable us to
distinguish between relative IRIs and terms/JSON keys. The presence of a
colon would enable us to distinguish between JSON keys and IRIs.."

I don't think we should discard all the descendant nodes if a property isn't
mapped to an IRI. I would rather say that this simply separates the graph
from the parent graph.

Let's continue the discussion directly in ISSUE-56 there.



--
Markus Lanthaler
@markuslanthaler
Received on Friday, 13 January 2012 22:55:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:36 GMT