New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it clear where prefixes are allowed and when they are interpreted as prefixes #38
Comments
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
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.
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.
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. |
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.
Yes, I think we noted this before, but the document never was updated. I'll take care of this. |
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. |
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. |
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. |
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. |
In the current spec it is not clear where prefixes (CURIES) are allowed. Are they just allowed in properties and objects or also in subjects!?
Do objects using prefixes have to be coerced using @iri? If so, how do we distinguish between IRIs and prefixes without using CURIE's square brackets? How do we distinguish between IRIs and prefixes in properties?
The text was updated successfully, but these errors were encountered: