Skip to content
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

Closed
lanthaler opened this issue Oct 22, 2011 · 9 comments

Comments

@lanthaler
Copy link
Member

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?

@lanthaler
Copy link
Member Author

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
Copy link
Member Author

_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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

gkellogg commented Nov 7, 2011

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
Copy link
Member Author

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
Copy link
Member

gkellogg commented Nov 7, 2011

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
Copy link
Member

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
Copy link
Member

msporny commented Jan 22, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants