W3C home > Mailing lists > Public > public-linked-json@w3.org > October 2011

RE: JSON-LD Java Implementation feedback.

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Sun, 23 Oct 2011 20:17:49 +0800
To: "'Fabian Christ'" <christ.fabian@googlemail.com>
Cc: "'Linked JSON'" <public-linked-json@w3.org>
Message-ID: <009101cc917d$ca81b760$5f852620$@lanthaler@gmx.net>
> How is a JSON-LD parser supposed to know whether some String
> is build using a prefix notation? Is it just by looking for
> a ":" in the string an trying to find a substitution for this?

A string which is going to be interpreted as a IRI will be split at the first occurrence of ":". If the prefix matches a term in the context definition it will be replaced and prepended to the (possible empty) suffix using textual concatenation.

See section 3.4 IRI Expansion in the API spec [1] for all the details.

> If you make it explicitly in the preamble what are prefixes
> and what are shortnames (token) there is one source for failure
> eliminated.

Which source of failure are you talking about?

> If you mix @prefixes and @token in @context you don't know which
> one is used for prefix substitution and which one is a shortname.
> A parser would have to do some try and error and maybe in case
> of name clashes you get unwanted results.

You don't have to know which one is used because you can't define it twice. Each term can be defined just once. If it used to replace a prefix, it won't be used again for the suffix. If there the is just a "shortname" the whole "shortname"  would be replaced according the term mapping defined in the context.

Again, see section 3.4 IRI Expansion in the API spec [1] for all the details.

> That's why I use either prefix notation or shortnames but avoid
> both in one serialization. Maybe a clever parser could do everything
> right but it makes things more complicated than necessary. And even
> for a human reader things become more clearly.

What exactly do you mean you avoid having both in one serialization? There was a long and controversial discussion about having prefixes (CURIEs). We decided that having a simple term definition where terms can be used as prefixes as well is simple enough to meet the design goals for JSON-LD. That's the reason why the term CURIEs has been avoided. Bringing in prefixes and namespaces would go too far in my opinion.

[1] http://json-ld.org/spec/latest/json-ld-api/#iri-expansion

Markus Lanthaler
Received on Sunday, 23 October 2011 12:18:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:18 UTC