RE: Expansion Algorithm

> >>> 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?)


Markus Lanthaler

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