RE: Precedence of @vocab

> > And that's exactly what happens here. It will be compacted to
> > schema:Document. I think the assumption was always that if you
> > specify a term or prefix in the context, than it should always
> > be preferred to a @vocab mapping.
> For terms yes, certainly. For prefixes I have to say no, as I hope you
> (all) will too. If a @vocab mapping is given, compaction should use
> that to avoid creating a compact IRI for a term. The purpose of
> compaction is to make the results as simple and usable as possible,
> and consumption of JSON with CURIE terms is problematic and
> undesirable. I strongly advice that @vocab is considered prior to
> making a compact IRI.

Seems reasonable and I tend to agree. I haven't thought enough about the
consequences of doing this yet to give a definite answer.

> That is putting step 6 prior to step 3, and rewriting the initial text
> to something like:

Yes, the change is indeed trivial.

> > You don't need to define a prefix in this case as @vocab is used here
> as
> > well. So you could simply write
> >
> >     "contributors": {"@id": "contributor", "@container": "@set"},
> >
> > Instead.
> Does @id in the context still resolve context terms and against
> @vocab? That seems odd. We have changed this behaviour for @id in the
> data (to avoid the clash with relative IRIs, and since these are
> normally resolved against the base IRI).

Yes, that's still being done. We change the behavior of @id in the body but
not in the context. Relative IRIs are not allowed in the context so there's
no risk of a clash.

> > That might be true.. but since there's only one vocab mapping, there
> number of prefixes you would have to reset is usually *very* small.
> Still, it would be preferable to not have to do this in order for
> @vocab to work effectively in compaction.

You are probably right. Could you create an issue for this so that we can
vote on it. I think since the change is so trivial we can resolve this even
before the next telecon. Thanks.

Have a nice weekend,

Markus Lanthaler

Received on Saturday, 30 March 2013 13:53:46 UTC