JSON-LD Telecon Minutes for 2012-01-24

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