W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2013

RE: review of json-ld-syntax

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 12 Mar 2013 19:15:30 +0100
To: "'W3C RDF WG'" <public-rdf-wg@w3.org>
Cc: "'Sandro Hawke'" <sandro@w3.org>
Message-ID: <017401ce1f4d$9596e480$c0c4ad80$@lanthaler@gmx.net>
Some more updates based on Sandro's feedback and the discussions in today's
JSON-LD telecon.

>  > JSON keys that do not expand to an absolute IRI are ignored, or
> removed in some cases, by the [JSON-LD-API]. However, JSON keys that do
> not include a mapping in the context are still considered valid
> expressions in JSON-LD documents-the keys just don't expand to
> unambiguous identifiers.
> This is kind of weird. It doesn't tell me what I'm supposed to do; it
> just confuses me.
> I guess it means they're like comments, and to be ignored?

This was changed to [1]

"JSON keys that do not expand to an IRI, such as status in the example
above, are not Linked Data and thus ignored when processed."

>  > 6.1 Compact IRIs
>  > Prefixes are expanded when the form of the value is a compact IRI
> represented as a prefix:suffix combination, and the prefix matches a
> term defined within the active context
>  > Terms are interpreted as compact IRIs if they contain at least one
> colon and the first colon is not followed by two slashes (//, as in
> http://example.com)
> These sentences contradict each other. Do slashes prevent recognizing
> things as compact IRIs or not? I'd suggest not -- that's just extra
> code that wont be helpful, IMHO. (TEST CASE?)

I've clarified the section and added two test cases in [2].

Values of the form prefix://suffix are not considered as compact IRIs to
prevent developers from accidentally overwriting all their http URLs for
example. RDFa had to introduce a similar safety-mechanism.

>  > It is a best practice to put the context definition at the top of
> the
> JSON-LD document.
> I don't agree. You're telling me I'm going against best practice to
> build and object in memory and let my JSON serializer turn it into

I changed it to the following suggestion [3]:

"When possible, the context definition should be put at the top of a JSON-LD
document. This makes the document easier to read and might make streaming
parsers more efficient. Documents that do not have the context at the top
are still conformant JSON-LD."

>  > To avoid forward-compatibility issues, a term should not start with
> an @ character
> Why only SHOULD NOT? Why not MUST NOT? The damage if they do is
> considerable.
> Also, you kind of need to say what processors MUST do if they see a
> keyword term they don't know -- ie one from the future. The options
> are: ignore (if you can figure out what/how much to ignore); or halt;
> or issue a warning to the user.

I've clarified that note [4]. Just as any other term that isn't mapped to an
IRI, terms starting with an "@" that are not keywords are being ignored.

>  > EXAMPLE 5
> after this example I was expecting the next example to use a Link
> header
> (what turns out to be EXAMPLE 29). Maybe mention it here?

The majority of the group felt that this is too early in the document. I've
added the following statement instead [5]:

"JSON documents can be transformed to JSON-LD without having to be modified
by referencing a context via an HTTP Link Header as described in section 6.8
Interpreting JSON as JSON-LD. It is also possible to apply a custom context
using the JSON-LD API [JSON-LD-API]."

>  > EXAMPLE 6 -- In the example above, the key http://schema.org/name is
> interpreted as an absolute IRI because it contains a colon (:) and the
> "http" prefix does not exist in the context.
> Now would be a perfect place to have a relative IRI example. You've
> just talked about there being absolute and relative IRIs, and given an
> example only of absolute ones.

I've added an example in [6].


Markus Lanthaler
Received on Tuesday, 12 March 2013 18:16:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:11 UTC