Manu Sporny: We had decided to use the same algorithm for IRI expansion on left-hand side and right-hand side.
… Gregg had wanted to try to make this consistent; the downside is that relative IRIs may be used on the left-hand side, which can conflict with keys.
… We wanted to have the JSON subtree completely ignored if keys are not mapped via @context.
… but, using a standard IRI expansion creates this undesirable side-effect, so maybe we should limit the left-hand side to terms, prefixed-values or absolute IRIs?
Niklas Lindström: Like TermOrCURIEorAbsIRI in RDFa...
Manu Sporny: We could keep it is, or adopt two different kinds of IRI expansion rules (key must be term, CURIE, or absolute IRI)
… the right-hand side may have those plus relative IRIs.
Niklas Lindström: It would be sound to use restricted left-hand side, but that only solves part of the problem.
… core of the problem exists on LHS or RHS: not clear if term is a relative IRI or a term.
Manu Sporny: We should probably split these issues.
… on the right-hand side, we know if a relative IRI is an active IRI or a term. The right-hand side uses a deterministic algorithm.
Manu Sporny: We could tell authors that they should use "./" or "/" notation for relative IRIs as a best practice, but not require it.
Markus Lanthaler: If we distinguish between left-hand side and right-hand side, it would not work within @context.
… This would mean that we can't use relative IRIs in @context.
Manu Sporny: Processing @context is a bit different than processing the body of the document.
Markus Lanthaler: If we have a way to distinguish between relative IRIs and terms, this would solve both issues. This also helps clarify the intent of the author.
Gregg Kellogg: I would support restricting the range of the left hand side to be TermsorAbsURIorCURIEs. [scribe assist by Manu Sporny]
Gregg Kellogg: I'm not in favor of requiring that relative IRIs begin with ./ or / or anything else that would require that all IRIs be normalized to remove that. [scribe assist by Manu Sporny]
Gregg Kellogg: You wouldn't be able to specify an IRI that doesn't contain a ./ or / - some schemes don't support that. [scribe assist by Manu Sporny]
Gregg Kellogg: What we have now is a deterministic algorithm... [scribe assist by Manu Sporny]
Markus Lanthaler: if we allow relative IRIs regardless of form, we have to do normalization, anyway.
Gregg Kellogg: I don't think we require normalization now... if we added ./, we'd require normalization. [scribe assist by Manu Sporny]
Gregg Kellogg: Normalization is not a part of any RDF grammar. [scribe assist by Manu Sporny]
Markus Lanthaler: So, would we disallow "./" ? [scribe assist by Manu Sporny]
Gregg Kellogg: No, we'd still allow it... maybe we include it as a best practice... but we shouldn't require "./" for relative IRIs. [scribe assist by Manu Sporny]
Manu Sporny: +1 to what Gregg said.
Manu Sporny: Requiring ./ would require that authors do something they don't need to do in any other language.
… This is pretty much the same as RDFa... you could use 'describedby' or 'next' in @resource in XHTML+RDFa and end up expanding out to xhv:next instead of something that is relative to BASE.
Niklas Lindström: It is exactly the case that we're in the same situation as RDFa.
… We have places where we use IRIs, CURIEs or terms. The value space for property (same as LHS) is always TermOrCurieOrAbsoluteIRI.
… For @resource, for example, it has the same confusion.
Niklas Lindström: Third option is to differ between @id or something different, such as @term, or something similar. This would allow a different value space on the LHS.
… This could allow a coercion similar to that used with @type.
Manu Sporny: Suggestion is to add a different keyword with a different value space.
Manu Sporny: Niklas' suggestion could be used, but this might not be an issue in practice.
… we can always introduce the feature later if we find that people are mixing up relative IRIs with terms.
Gregg Kellogg: I don't think there is a case where we have a keyword where the range is different... it's really the left-hand side issue where there is no keyword involved. [scribe assist by Manu Sporny]
Gregg Kellogg: I think we should keep things as is with respect to the algorithm, other than restricting the range of the left-hand side. [scribe assist by Manu Sporny]
Manu Sporny: Discussion is about allowable range of LHS and RHS.
… ISSUE-56 is related, but different.
PROPOSAL: Constrain the left-hand side of JSON-LD key-value statements by only allowing terms, or prefixed-values, or absolute IRIs.
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +1, sounds good
RESOLUTION: Constrain the left-hand side of JSON-LD key-value statements by only allowing terms, or prefixed-values, or absolute IRIs.
PROPOSAL: Allow terms, or prefixed-values, or absolute IRIs or relative IRIs on the right-hand side of JSON-LD key-value statements.
Niklas Lindström: +1
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: Allow terms, or prefixed-values, or absolute IRIs or relative IRIs on the right-hand side of JSON-LD key-value statements.
Topic: Lexical Space for Terms in the Document
PROPOSAL: If the right-hand side of a JSON-LD key-value statement is a relative IRI, and if a mapping exists in the @context for that value, the value expands to the value in the mapping in the @context.
Gregg Kellogg: Could "a/b" be in the key position of a context? [scribe assist by Manu Sporny]
Markus Lanthaler: we just decided the following: "Constrain the left-hand side of JSON-LD key-value statements by only allowing terms, or prefixed-values, or absolute IRIs."
Manu Sporny: right now, we always try to resolve and either ignore (RHS) or use as relative IRI.
Ted Thibodeau Jr.: This proposal sounds redundant... doesn't this all just boil down to order of operations? [scribe assist by Manu Sporny]
Manu Sporny: Yes, it is redundant, but we don't have an agreement on the record of this is how we do this stuff. [scribe assist by Manu Sporny]
Niklas Lindström: there is confusion about if "a/b" can be interpreted as a term. Most people's instinct is probably no, but it is similar to something that cropped up in RDFa.
Niklas Lindström: knows/friend
… schema.org uses "/" to describe sub-properties.
… also Facebook's open graph, which has multiple ":" characters, making it a bit more complicated.
… issue is, can terms contain '/' or ':'.
Markus Lanthaler: terms are NCNAME or blank, so no, they can't contain those characters.
Ted Thibodeau Jr.: if we're going to make a general statement and create many special cases, the document becomes unusable.
… We should define order of rule application; this covers random special cases.
… We could describe in a note that something may be confusing.
Niklas Lindström: the core issue is that relative IRIs and terms are very close to each other, and we don't know how people will want to use them.
Manu Sporny: rule as written now is not ambiguous; you look up the exact value and perform expansion if it exists, otherwise split on ":" and expand a prefix if mapped, otherwise it's an IRI.
Markus Lanthaler: that could lead to prefixes which contain ':'.
Manu Sporny: we should not mandate that relative IRIs start with (e.g.) "./"
Gregg Kellogg: I think one of the use cases of JSON-LD is to provide meaning to existing documents... they may not conform to our ideas of what is in the key position... it might contain something that looks like a relative IRI. [scribe assist by Manu Sporny]
Gregg Kellogg: We should be inclusive... so, we may want to allow something that looks like relative IRIs on the left-hand side. [scribe assist by Manu Sporny]
Gregg Kellogg: if you did that, you could create a context that applies to somebody else's JSON, which provides a mapping for that. [scribe assist by Manu Sporny]
Niklas Lindström: including arbitrary JSON is problematic, as we might not be doing enough: the meaning of the key something different. In RDF/JSON, the key can be the subject.
… we'll shoot ourselves in the foot if we're too inclusive.
Manu Sporny: better to start of being too restrictive, and add support if the use cases support it.
Niklas Lindström: perhaps "@container" could be a powerful construct, to allow e.g. @languagemap or @irimap, enabling more complex things predictibly.
PROPOSAL: The lexical space for keys in JSON-LD key-value statements is - if a term - NCName, if a prefix - NCName for the prefix, otherwise the lexical space for an absolute IRI.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +0
Niklas Lindström: +0.5
Ted Thibodeau Jr.: +0
RESOLUTION: The lexical space for keys in JSON-LD key-value statements is - if a term - NCName, if a prefix - NCName for the prefix, otherwise the lexical space for an absolute IRI.
Topic: Lexical Space for Keys in @context
PROPOSAL: The lexical space for keys in JSON-LD Context key-value statements is - if a term - NCName, if a prefix - NCName for the prefix, otherwise the lexical space for an absolute IRI.
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +0
Ted Thibodeau Jr.: +1
RESOLUTION: The lexical space for keys in JSON-LD Context key-value statements is - if a term - NCName, if a prefix - NCName for the prefix, otherwise the lexical space for an absolute IRI.