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

RE: Expansion Algorithm

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 6 Dec 2011 18:16:51 +0800
To: <public-linked-json@w3.org>
Message-ID: <00df01ccb400$2e9be4b0$8bd3ae10$@lanthaler@gmx.net>
> >>> 2) {"foaf:homepage", {"@iri": "ex:home"} should cause "ex:home" to
> be
> >>> expanded, whether or not "foaf:homepage" is subject to  coercion
> >> Agree
> >
> > I guess the point of this one is if a @coerce rule exists but the
> > document didn't follow the rule? If my understanding is correct here,
> I
> > agree.
> The point is either if foaf:homepage has a coerce rule or not, but "ex"
> is defined as a term that the algorithm should descend into the @iri
> object to expand ex:home. Looking at the spec it says nothing about
> expanding values where the key is "@iri". TO make this happen, we need
> to be clear that "@iri" is defined to have an implicit coercion rule of
> {"@iri": {"@datatype": "@iri"}}, which shouldn't be too much of a
> stretch.

I think we are already quite clear about that in the spec. We define in [1]
that "an IRI is generated when a value is associated with a key using the
@iri keyword" and that "IRIs may be represented as an absolute IRI, a term,
a prefix:suffix construct".

> >>> 3) {"@subject": "ex:home", "@type": "foaf:Document"} should cause
> both
> >>> "ex:home" and "foaf:Document" to be expanded
> >> Agree
> >
> > Provided that "ex" and "foaf" are defined prefixes, I agree.
> This also requires specific coercion rules. Furthermore, expanding
> relative IRIs needs to be clear, because one might be relative to
> @base, while the other relative to @vocab". (I'm coming around to
> removing one, the other, or both, but we do need to think about how to
> resolve relative IRIs non-the-less).

I agree that we need to be much more clear about expanding relative IRIs and
how to expand them. We also need to define how we distinguish a relative IRI
from an absolute one and whether we support/require IRI normalization
(ISSUE-46, [2]).
Removing @base and @vocab (ISSUE-26, [3]) would make it much easier to read
a JSON-LD document in my opinion and we don't lose much (any?)

[1] http://json-ld.org/spec/latest/json-ld-syntax/#iris
[2] https://github.com/json-ld/json-ld.org/issues/46
[3] https://github.com/json-ld/json-ld.org/issues/26

Markus Lanthaler
Received on Tuesday, 6 December 2011 10:17:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:32 UTC