Re: Precedence of @vocab

Hi Markus,

On Fri, Mar 29, 2013 at 7:05 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> Hi Niklas,
>
>
>> results in:
>>
>>     {
>>       "@type": "Document",
>>       "name": "Something"
>>     }
>>
>> I believe that compaction is specified like this, according to in "8.3
>> IRI Compaction" [1]:
>>
>> > we first try to find a term that the IRI or keyword can be compacted
>> to if it is relative to active context's vocabulary mapping.
>
> You are citing the non-normative overview here. "Document" is neither a term
> (there's no "Document" entry in the context) nor a keyword. So this step
> will fail. If you read on, the text says:
>
> "If no term was found that could be used to compact the IRI, then an attempt
> is made to find a compact IRI to use."

You're right. Then this is a problem.

> 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.

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

    "If no term was found that could be used to compact the IRI, then
an attempt is made to construct one based on the active context's
vocabulary mapping, if there is one. If no such term can be
constructed, then an attempt is made to find a compact IRI. If there
is no appropriate compact IRI, the IRI is transformed to a relative
IRI using the document's base IRI. Finally, if the IRI or keyword
still could not be compacted, it is returned as is."

>
>> .. Of course, in the above example, just removing the "schema" term
>> would do the trick. But in practice, it is often useful to both set a
>> default vocabulary and also have a prefix for the same IRI, in order
>> to e.g. rename certain terms (and relying on prefixes to shorten the
>> context size). E.g. to make plural forms of terms with a `@container`
>> of `@set` or `@list, like:
>>
>>         "contributors": {"@id": "schema:contributor", "@container":
>> "@set"},
>>         ...
>>
>> (Or for specific datatyped values, or terms with predefined language,
>> etc.)
>
> 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).

>
>> Moreover, sometimes you want to have a list of contexts, the first
>> defining common prefixes and the latter declaring your specific
>> context needs. While you can end by setting a `@vocab` and then
>> setting any prefix with that same value to `null`, that can be brittle
>> and cumbersome.
>
> 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.

Cheers,
Niklas


>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Friday, 29 March 2013 18:46:23 UTC