Make it clear where prefixes are allowed and when they are interpreted as prefixes about json-ld.org

[lanthaler]

Update based on conversation on mailing list. See Gregg's answer and my reply:

How are terms and prefixes interpreted in context definitions? Are they allowed there? I think that could help in some situations but cause more troubles than advantages (recursive mappings, copy-and-paste errors, ...).

In the API spec, section 3.4 IRI Expansion the sentence

    IRIs may be represented as an absolute IRI, a term, a prefix:term
    construct, or as a value relative to @base or @vocab.

is a bit misleading because the prefix is used as a term and not the suffix. So either we change it to prefix:suffix or to term:suffix.

    > If the string has a prefix or term mapping, it's used to
    > create the IRI. Otherwise, it is joined to either @vocab
    > or @base.

Does that means that if there is a prefix or term mapping, @vocab and @base won't be used? I understand API spec 3.4 that @vocab and @base will be used regardless of that - assuming that it is a relative IRI (which isn't mentioned at all!).

This would imply that prefix/term mappings would have to be absolute IRIs, is that how it is intended to be? If so we should specify that. At the moment, all the examples use absolute IRIs.

    > > How do we distinguish between IRIs and prefixes in
    > > properties?
    >
    > Based on the presence of the mapping. API 3.4 makes this
    > unambiguous.

OK, so if there is a mapping, it will be used. We should highlight that also in the syntax spec, possibly in section 3.1 IRIs.

[lanthaler]

_Gregg said:_

Terms and prefixes MAY be used in the @Coerce section, but not in @context. All IRIs (including @base) MUST be in the form of an absolute IRI; I'll make this clear in both docs.

> In the API spec, section 3.4 IRI Expansion the sentence
> 
> "IRIs may be represented as an absolute IRI, a term, a prefix:term 
> construct, or as a value relative to @base or @vocab."
> 
> is a bit misleading because the prefix is used as a term and not the suffix.
> So either we change it to prefix:suffix or to term:suffix.

Yes, I think we noted this before, but the document never was updated. I'll take care of this.

[lanthaler]

Most of this has already been addressed in the latest spec updates.

I would just like to see some of this also in the Vocabulary Prefixes section in the syntax spec. Especially that prefixes MAY be used in the @Coerce and the data(?) section but not in @context.

[lanthaler]

I've highlighted the fact that term mappings and @vocab definitions have to be in the form of absolute IRIs in 9830cf4.

We still have to decide where prefixes are allowed in the context.

[gkellogg]

I described prefixes/terms as being allowed in @Coerce and in the active context when processing a context. That is, you can use a term in place of an IRI in a @context term value if it was defined in a context which is in-scope when beginning to process the current context. We might also want something about @vocab from the current context definition, but that creates a potential order dependency.

Note that @Coerce allows term, prefix:suffix or array of same as values and also allows @iri or @list as keys (this will change when they're re-ordered). Should probably also allow absolute IRI, or possibly a relative IRI resolved against in-scope @vocab.

This needs to be re-considered if/as/when we remove @Coerce and place inline with term definitions.

[lanthaler]

I don't think we need to consider @vocab here since term (and therefore also prefix) definitions have to use absolute IRIs. Or were you talking about supporting terms/prefixes in @vocab? I don't see any problems with that, neither in supporting them in @base.

That would in fact simplify the spec as we could simply say wherever IRIs are allowed, also terms/prefixes are allowed.

[gkellogg]

I'm looking to be more consistent in general. There should be an active context when evaluating anything, and IRI generation should be consistent. This could include using @vocab from the context being processed, if it updates the active context first; that would allow Niklas' examples.

Basically, anywhere you can expect an IRI you use the same processing rules including term and prefix expansion. The only parameter required is whether relative IRIs should be expanded using @base or @vocab; it's usually @vocab, except for subject or object positions.

[gkellogg]

Now that @vocab and @base have been removed, and it has been made clear that CURIEs may be used in @context (except for key position, which is the subject of issue #43). I'm closing this issue.

[msporny]

http://json-ld.org/spec/ED/json-ld-syntax/20120122/#iri-expansion-within-a-context