- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 25 Jan 2012 21:38:20 -0500
- To: Linked JSON <public-linked-json@w3.org>
Thanks to Gregg for scribing! I updated the scribe tool to make the minutes look a tiny bit prettier and summarize the topics and resolutions discussed. The minutes for yesterday's call are now available here: http://json-ld.org/minutes/2012-01-24/ Full text of the discussion follows, as well as a link to the complete audio transcript: -------------------- JSON-LD Community Group Telecon Minutes for 2012-01-24 Agenda: http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0095.html Topics: 1. ISSUE-49: Relative IRIs may clash with terms 2. Lexical Space for Terms in the Document 3. Lexical Space for Keys in @context Resolutions: 1. Constrain the left-hand side of JSON-LD key-value statements by only allowing terms, or prefixed-values, or absolute IRIs. 2. Allow terms, or prefixed-values, or absolute IRIs or relative IRIs on the right-hand side of JSON-LD key-value statements. 3. 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. 4. 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. Chair: Manu Sporny Scribe: Gregg Kellogg Present: Gregg Kellogg, Manu Sporny, Markus Lanthaler, Niklas Lindström, David I. Lehn, Ted Thibodeau Jr. Gregg Kellogg is scribing. Manu Sporny: Any changes to the agenda? Markus Lanthaler: We should discuss disjoint graphs Manu Sporny: yes, the use of @id with list of objects, each having an @id is a strange … way of representing disjoint graphs which is not ideal... although it's the best solution we have besides re-introducing something like @graph. Markus Lanthaler: The issue is being tracked here: https://github.com/json-ld/json-ld.org/issues/68 … Also related to keys that don't map to an IRI, which could also be used to define disjoint graphs. Manu Sporny: We have all related issues in the tracker... should be covered with existing issues. Topic: ISSUE-49: Relative IRIs may clash with terms Manu Sporny: https://github.com/json-ld/json-ld.org/issues/49 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. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc. blog: PaySwarm vs. OpenTransact Shootout http://manu.sporny.org/2011/web-payments-comparison/
Received on Thursday, 26 January 2012 02:38:52 UTC