JSON-LD Telecon Minutes for 2013-10-15

Thanks to Dave Longley for scribing! The minutes from this week's 
telecon are now available.

http://json-ld.org/minutes/2013-10-15/

A full transcript of the meeting can be found below. Audio for the call
is available at the link provided above.

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-10-15

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2013Oct/0038.html
Topics:
    1. Plan for Proposed Recommendation
    2. How to refer to Promises
    3. Does non-normative API require another LC?
    4. Removing at risk markers from JSON-LD specs.
    5. Updated Implementation Report
    6. Candidate Recommendation Period
Resolutions:
    1. Make the JSON-LD WebIDL API non-normative and refer to the
       Promises specification written by Domenic Denicola and proceed
       straight to Proposed Recommendation.
    2. Allow blank nodes to be used as graph name or property.
    3. Support conversion of lists of lists to list objects by
       preserving the blank node head of the inner list. This resolves
       feature-at-risk #4 in the JSON-LD API specification.
    4. Make an editorial update to the JSON-LD specification to
       clarify that the @type keyword is context sensitive and make its
       various usages more clear in the specification. This addresses
       issue at risk marker #9 in the JSON-LD syntax specification.
    5. Keep the @base: null feature in the JSON-LD specification
       as it is defined in the Candidate Recommendation specification.
    6. When processing free-floating nodes, if there is an @index
       keyword in the node, it is not a free-floating node.
    7. The Candidate Recommendation period for JSON-LD is closed
       as of October 15th 2013.
Action Items:
    1. Sandro to ask W3C legal about archiving Promises spec at
       W3C.
    2. Manu to outline path forward for Promises reference to RDF
       WG and get input from W3C Director on the path forward.
    3. Manu to send an email to RDF WG stating that all issue
       markers are resolved.
Chair:
    Manu Sporny
Scribe:
    Dave Longley
Present:
    Dave Longley, Manu Sporny, Sandro Hawke, Gregg Kellogg, Markus
    Lanthaler, Niklas Lindström, Paul Kuykendall, David I. Lehn,
    Gavin Carothers
Audio:
    http://json-ld.org/minutes/2013-10-15/audio.ogg

Dave Longley is scribing.
Manu Sporny:  we'll be talking about the plan for PR and an
    update from gregg on implementation reports
Sandro Hawke:  my email probably raised some things we should
    discuss
Manu Sporny:  yeah, the first item on the agenda will cover that
Manu Sporny:  the argument for not going through another LC/CR,
    etc.

Topic: Plan for Proposed Recommendation

Manu Sporny:  the last time we talked about this, we thought we
    were pretty close to going to PR, the blocker was RDF-CONCEPTS
    still being in LC
Manu Sporny:  from what i gather, it was discussed on the RDF WG
    call and the proposed path forward is to wait for RDF-CONCEPTS to
    go to CR and then we can move JSON-LD specs to PR
Sandro Hawke:  it's not exactly clear when RDF-CONCEPTS will be
    ready to move forward, it's possible we may make that discussion
    tomorrow, it's due to a bunch of comments
Sandro Hawke:  i think we'll have a formal objection from Jeremy
    Carroll
Gregg Kellogg:  that's with semantics, not concepts
Sandro Hawke:  they go together
Gregg Kellogg:  if we move concepts first we can prevent JSON-LD
    from getting blocked
Sandro Hawke:  i think they are both clear to go ahead, there
    will be some loose ends, my guess is it won't be tomorrow but
    probably two weeks
Gregg Kellogg:  so a matter of a couple of weeks
Manu Sporny:  the RDF WG charter is up in december
Manu Sporny:  is it going to extended?
Sandro Hawke:  no
Sandro Hawke:  as long as we get to PR by the end of the december
Manu Sporny:  there are no big blockers other than Jeremy
    Carroll's FO, but that will be resolved because the group will
    continue ahead
Sandro Hawke:  yup
Manu Sporny:  ok, thanks
Manu Sporny:  so we'll go into a holding pattern until
    RDF-CONCEPTS goes into CR
Markus Lanthaler:  we need to talk about Promises
Manu Sporny:  yes, that's next, we still need to talk about the
    issues that sandro raised
Manu Sporny:  whether or not we're going to make the API
    non-normative per the issue-at-risk comment, etc.

Topic: How to refer to Promises

Manu Sporny:  if we make the section non-normative we still need
    to reference some spec out there
Markus Lanthaler:  the problem is there is no specification at
    the moment, we could use a reference to the DOM spec, but we know
    that won't be the final spec, eventually it's going to end up
    directly in ECMAScript (JS spec)
Markus Lanthaler:  up until a week ago i didn't see any mentions
    in the spec
Markus Lanthaler:  the hope is that it will be published in
    december
Markus Lanthaler:  google has an implementation but doesn't ship
    until, i think, november
Markus Lanthaler:  i don't know the state in firefox
Markus Lanthaler:  it's up in the air in the moment
Sandro Hawke:  i think for non-normative, i think we could
    reference the historic DOM spec of it, we could say,
    specifically, we know this isn't the final thing, but for now
    this is what people can use and when something better comes along
    they should switch to it, there should be no procedural blocker
Sandro Hawke:  i think we just need to point at something that
    developers can read and be clear about it
Markus Lanthaler:  are there any restrictions as far as W3C is
    concerned?
Sandro Hawke:  if it's not a W3C spec, it's more of a judgment
    call about how stable it is, there's no clear way to say what is
    a stable spec from somebody else
Markus Lanthaler:  it would mean... even if we had an ecmascript
    draft we could argue it's stable enough, because, for example,
    chrome already implemented it
Sandro Hawke:  if we had an ecmascript draft and it was
    implemented in chrome and firefox and we could go ahead with a
    normative reference, it would be a bit of stretch, but we could
    argue that, the ecmascript spec being ready in december may not
    actually happen
Sandro Hawke:  we have a little bit of slack because of these
    other docs (concepts, and semantics) so we could just wait until
    then and there's an ecmascript draft by december 1st then we can
    use it
Manu Sporny:  i just asked Anne which draft we should reference
Manu Sporny:  he gave me the link in IRC
Manu Sporny: Anne says we should reference this draft:
    https://github.com/domenic/promises-unwrapping/blob/master/README.md
Sandro Hawke:  i think it would be ok to use a github URL
    presuming it was frozen in time
Sandro Hawke:  if we have permission to copy that to w3c
Gregg Kellogg: Here's a frozen version:
 
https://raw.github.com/domenic/promises-unwrapping/7e845e44045e4063c1e48cd3cfcab419620ae59b/README.md
Niklas Lindström: "To the extent possible under law, Domenic
    Denicola has waived all copyright and related or neighboring
    rights to promises-unwrapping."
Manu Sporny:  this isn't ecmascript, this is a doc in the public
    domain
Sandro Hawke:  what i heard was that dom's employer has some
    copyright claim to that text and hasn't been willing to do the
    appropriate paperwork
Manu Sporny:  we could use a pointer to a specific version of it
Markus Lanthaler: scroll to the bottom, the document says: "To
    the extent possible under law, Domenic Denicola has waived all
    copyright and related or neighboring rights to
    promises-unwrapping. This work is published from: United States
    ."
Manu Sporny:  the assumption we're making is that github will be
    around for at least 3 years, and at that point hopefully we'll
    have another link we can reference
Sandro Hawke:  if the link happens to break it becomes a matter
    of archeology and people should be able to deal with that
Sandro Hawke:  digital bazaar or somebody could checkout that
    repo and make it available on the web
Sandro Hawke:  i haven't looked at the license
Sandro Hawke:  it could just be that ecmascript has a really high
    bar on that
Manu Sporny:  he's put it into the public domain and if google
    didn't want to do that, but i have no idea what google would want
    to come in and establish copyright over something going into ecma
Sandro Hawke:  do you want me to go ahead and ask w3c's lawyers
    if we can make a copy of that
Manu Sporny:  sure, you could ask
Sandro Hawke:  normally we're happy to take the employee as
    clicking somewhere as sufficient
Sandro Hawke:  we use their own word for it
Sandro Hawke:  i'll do that
Manu Sporny:  thanks
Markus Lanthaler:  it looks like dom is not working for google
Gregg Kellogg: How to write specs using Promises:
 
https://github.com/domenic/promises-unwrapping/blob/7e845e44045e4063c1e48cd3cfcab419620ae59b/writing-specifications-with-promises.md
Markus Lanthaler: http://www.linkedin.com/in/domenicdenicola
Markus Lanthaler:  he's working for Lab49
Markus Lanthaler:  if the api would stay normative, would it
    change anything in regards to that linking?
Sandro Hawke:  to stay normative we would need to clear up the
    legal thing about this text and then argue that it is stable
    because of implementations, for instance, in chrome and firefox
Markus Lanthaler:  but it's not a problem per se
Markus Lanthaler:  it's not disallowed to link to something like
    this, for example
Sandro Hawke:  it's not strictly disallowed, no
Sandro Hawke:  we'd just have to make the argument that the
    technology is stable
Sandro Hawke:  if we can copy the text to our site then the text
    won't change and then it's just whether or not the technology is
    stable
Manu Sporny:  i'm guess that it's going to happen soon
    w/ecmascript, but maybe not before we need it to happen

ACTION: Sandro to ask W3C legal about archiving Promises spec at W3C.

Manu Sporny:  ok and we'll just refer to that doc if we can

ACTION: Manu to outline path forward for Promises reference to RDF WG 
and get input from W3C Director on the path forward.


Topic: Does non-normative API require another LC?

Manu Sporny:  if the change is from normative to non-normative do
    we need to do another CR/LC, etc
Manu Sporny:  sandro raised the point that we could make the
    argument that we don't need another LC, i thought we had
    predicted that this might happen and we put in spec text so we
    wouldn't have to go through another round
Manu Sporny:  markus, is that spec text is in there?
Manu Sporny:  saying the API could become non-normative
Markus Lanthaler:  no, we just said that the reference might
    change
Sandro Hawke:  we put an at-risk warning in there, but we phrased
    it as we might change the reference, we didn't include that we
    might take the whole API and make it non-normative
Markus Lanthaler:  if it's somehow possible it would really make
    sense to keep the API normative, i'm not a big fan of making it
    non-normative
Sandro Hawke:  i think we can only do that if we really have 2
    implementations
Manu Sporny:  a generous reading of the at-risk marker would be
    to say ... one way to refer to a spec that lives elsewhere is to
    make the reference non-normative and refer to it
Manu Sporny:  if we had said in this feature at-risk marker,
    "this section might become non-normative as a result of us trying
    to figure out how to refer to a spec outside of the w3c" then
    we'd be fine
Manu Sporny:  however that spec text does not exist, what i'm
    looking for is some text in this spec is to see if we can change
    the spec in the way we need to
Manu Sporny:
    https://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk#8
Manu Sporny:  i think the language hints at us needing to do
    something other than just updating the reference
Sandro Hawke:  because we have that at-risk we have some argument
Sandro Hawke:  i think the change we want to make is covered by
    that, it's not literally covered by that, but it's close enough,
    and i think we want to try to make that argument, and if we get
    push back we can do another LC, but we really don't want to do
    that
Markus Lanthaler: here's the link to the Chromium Promise issue:
    https://codereview.chromium.org/24980002 - it's already
    implemented
Sandro Hawke:  to make that case, i think ralph, acting as
    director on this, will ask if it will invalidate any reviews
Sandro Hawke:  is there anyone who is going to be unhappy about
    this change
Manu Sporny:  i think the answer to that is no
Manu Sporny:  i don't think any changes to implementations will
    happen
Sandro Hawke:  i think the only people who would be unhappy about
    this would be people thinking strategically who want it
    normative, but they'd also understand that this was a change we'd
    have to make
Sandro Hawke:  ideally we should gather some comments from people
Sandro Hawke:  as evidence
Sandro Hawke:  have we gotten any comments from anyone about
    Promises
Manu Sporny:  we have lots of comments from industry about
    Promises, we could collect comments from people about Promises,
    saying Promises are a good thing and a good direction to go
Manu Sporny:  the question is, would that helpful because we're
    creating something non-normative here
Sandro Hawke:  i don't think that's particularly helpful
Sandro Hawke:  so normally, the director doesn't make decisions
    until you have the meeting
Sandro Hawke:  and we're waiting a couple weeks for those
    references
Sandro Hawke:  we could try to have the transition now and wait a
    couple weeks and fix the references, but in case the answer is
    no, we want to have time for LC
Manu Sporny:  could you get ralph to look at this to get an
    answer
Manu Sporny:  i could write an email asking if it's ok with RDF
    WG and point ralph at it, and ask if it was fine to go into the
    transition meeting like that
Sandro Hawke:  i'd like to get a binding yes or no from him, we
    don't want it to change later
Sandro Hawke:  ok, you write that email
Sandro Hawke:  i'm thinking that we should try to get a WG
    resolution from that tomorrow
Sandro Hawke:  the other thing that ralph cares a lot about is
    whether or not the WG has discussed it and come to a resolution

PROPOSAL: Make the JSON-LD WebIDL API non-normative and refer to
    the Promises specification written by Domenic Denicola and
    proceed straight to Proposed Recommendation.

Manu Sporny: +1
Gregg Kellogg: +0.5
Sandro Hawke: +1
Paul Kuykendall: +1
Dave Longley: +1
Markus Lanthaler: +0.1
David I. Lehn: +0
Niklas Lindström: +0
Sandro Hawke:  why the weak support? [scribe assist by Sandro
    Hawke]
Gregg Kellogg:  I just wish there were a way to keep it normative
    [scribe assist by Sandro Hawke]
Niklas Lindström: (I don't feel properly informed to judge the
    strategic effects of either route)
Gregg Kellogg:  I think it's unfortunate that this can't be a
    normative section, but understand that this is the best of
    available solutions [scribe assist by Gregg Kellogg]

RESOLUTION: Make the JSON-LD WebIDL API non-normative and refer
    to the Promises specification written by Domenic Denicola and
    proceed straight to Proposed Recommendation.

Manu Sporny:  could the non-plus-1's explain why?
Manu Sporny:  gregg wants it to be normative but doesn't see how
    we could do that
Markus Lanthaler:  with making it non-normative it will be
    impossible to build applications on top of the API in an
    interoperable way [scribe assist by Markus Lanthaler]
Gregg Kellogg:  it's useful to note that we don't actually have
    any tests that use Promises, my implementation doesn't implement
    them and i think other ones don't as well
Gregg Kellogg:  it's really narrow, for JS in particular
Sandro Hawke:  has someone done the editorial change, is it all
    of the API?
Sandro Hawke:  so it's just how you talk to the algorithms that
    becomes non-normative
Sandro Hawke:  all the at-risk stuff has to come out before we go
    to PR
Manu Sporny:  yeah, that's unfortunate, so maybe next week we
    will go through all of those and then pass it off to the RDF WG
Sandro Hawke:  as long as the CG is unanimous about all of them
    we'll probably sign off on them
Sandro Hawke:  in the WG
Paul Kuykendall:  is there a way for us to have preliminary info
    on which way the at-risk markers will go
Paul Kuykendall:  maybe on the mailing list
Sandro Hawke:
    https://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk
Manu Sporny:  the risk with doing that is that people will start
    debating them

Topic: Removing at risk markers from JSON-LD specs.

Manu Sporny:  at great length
Manu Sporny:  ok, we have resolutions on a lot of these
Manu Sporny:  i think we have a generalized RDF flag for blank
    nodes in the property position

PROPOSAL: Allow blank nodes to be used as graph name or property.

Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Markus Lanthaler: this is feature at risk 3
David I. Lehn: +1
Niklas Lindström: (given the "use-generalized-rdf" set to true
    (default is false) for blank nodes as properties)
Sandro Hawke: +1

RESOLUTION: Allow blank nodes to be used as graph name or
    property.

Niklas Lindström: .. which is the case. :)
Sandro Hawke:  if we can point to public comments for each of
    these it would be the strongest way forward
Dave Longley:  We do want to make sure that if the RDF WG sees
    this that they understand that there is a use_generalized_rdf
    flag [scribe assist by Manu Sporny]
Markus Lanthaler:  i think the list of lists at-risk marker we
    didn't resolve completely

PROPOSAL: Support conversion of lists of lists to list objects by
    preserving the blank node head of the inner list. This resolves
    feature-at-risk #4 in the JSON-LD API specification.

Manu Sporny: +1
Markus Lanthaler: +1
Dave Longley: +1
Paul Kuykendall: +1
David I. Lehn: +0
Gregg Kellogg: +1
Niklas Lindström: +1 (better than dropping them)
Sandro Hawke: +1

RESOLUTION: Support conversion of lists of lists to list objects
    by preserving the blank node head of the inner list. This
    resolves feature-at-risk #4 in the JSON-LD API specification.

Manu Sporny:  we've had a number of JSON-LD authors about having
    @type having a different meaning
Manu Sporny:  based on context
Manu Sporny:  we've had several different discussions about
    renaming it in different contexts, but it hasn't really gone
    anywhere, with a little explaining it seems like people are ok
    with it as is
Markus Lanthaler: We might wanna do some editorial changes, see:
    https://github.com/json-ld/json-ld.org/issues/301
Manu Sporny:  can we make a 2-3 sentence editorial change before
    we go to PR?
Sandro Hawke:  as long as it's just editorial and particularly if
    it's responding to a comment it's fine
Paul Kuykendall:  i think reading a tutorial will easily cover
    this

PROPOSAL: Make an editorial update to the JSON-LD specification
    to clarify that the @type keyword is context sensitive and make
    its various usages more clear in the specification. This
    addresses issue at risk marker #9 in the JSON-LD syntax
    specification.

Manu Sporny: +1
Paul Kuykendall: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +0.9
Dave Longley: +1
David I. Lehn: +1

RESOLUTION: Make an editorial update to the JSON-LD specification
    to clarify that the @type keyword is context sensitive and make
    its various usages more clear in the specification. This
    addresses issue at risk marker #9 in the JSON-LD syntax
    specification.

Manu Sporny:  Ok, we also need to talk about @base: null. I think
    consensus is that we keep it. Object if you disagree.

PROPOSAL: Keep the @base: null feature in the JSON-LD
    specification as it is defined in the Candidate Recommendation
    specification.

Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Sandro Hawke: +1
David I. Lehn: +1
Niklas Lindström: +0 (I cannot really judge the effect on
    usability)
Markus Lanthaler: +0

RESOLUTION: Keep the @base: null feature in the JSON-LD
    specification as it is defined in the Candidate Recommendation
    specification.

Markus Lanthaler: neither do I
Manu Sporny:  ok, so if we can get that raised in the RDF WG call
    tomorrow
Gregg Kellogg:  i may not be on the call tomorrow
Sandro Hawke:  ideally, if you can send an email nowish right
    after this call it can be on the agenda

ACTION: Manu to send an email to RDF WG stating that all issue markers 
are resolved.

Topic: Updated Implementation Report

Manu Sporny:  pkuyken got a C# implementation report in
Gregg Kellogg:  it's in the comprehensive report now as is rdflib
    from niklasl
Gregg Kellogg:  and jsonld-java
Gregg Kellogg:  it's 100% except for a couple of tests they
    didn't cover
Markus Lanthaler: just realized we still haven't resolved
    ISSUE-300 https://github.com/json-ld/json-ld.org/issues/300
Gavin Carothers:  Some note pointing out that @base: null makes
    toRDF not work may prevent surprises
Gregg Kellogg:  the java implementation doesn't handle remote
    docs
Paul Kuykendall:  we had problems with that because some remote
    docs didn't exist
Gregg Kellogg:  that's intentional it is testing that they don't
    exist
Paul Kuykendall:  is that documented?
Gregg Kellogg:  yes
Gregg Kellogg: http://json-ld.org/test-suite/reports/
Dave Longley:  is it ok that some implementation reports haven't
    gone to public-rdf-comments but only to public-linked-json
Sandro Hawke:  either is fine
Gregg Kellogg:  minus some sporadic errors i think we're showing
    broad support for a variety of platforms
Manu Sporny:  yeah, thanks to all implementors
Sandro Hawke: probably me.  I don't think I hung up properly.
Markus Lanthaler:  the current status keeps @index nodes
Gregg Kellogg:  do we have a test?
Markus Lanthaler:  yes, and it keeps it
Niklas Lindström:  if you use @index it's probably computed from
    some other value in the node
Markus Lanthaler:  the only reason to perhaps drop it is to be
    more consistent
Manu Sporny:  do we have spec text that covers this
Markus Lanthaler:  i would argue it's just a bug fix
Gregg Kellogg:  it would require implementations to change and
    removing a test and adding another one and asking for updated
    implementation reports
Manu Sporny:  the alternative is that we say nothing about it,
    and after we put the spec out we can make these changes
Niklas Lindström:  i'm in favor of keeping it, i could imagine
    some implementation using it
Niklas Lindström:  it could, in theory, be destroying information
    in some strange algorithm outside of what we've specified
Niklas Lindström:  i'm in favor of keeping the nodes which is the
    current behavior and it might support some unforeseen behavior

PROPOSAL: When processing free-floating nodes, if there is an
    @index keyword in the node, it is not a free-floating node.

Manu Sporny: +0.7
Markus Lanthaler: +0.5 (not entirely consistent IMO but I'm fine
    with it and don't feel strongly about it)
Dave Longley: +1
Gregg Kellogg: +1
David I. Lehn: +0
Paul Kuykendall: +0 Not enough understanding of the problem
Niklas Lindström: +0.5

RESOLUTION: When processing free-floating nodes, if there is an
    @index keyword in the node, it is not a free-floating node.

Niklas Lindström:  It might be good to tell people using toRDF
    that blank node properties could be created. [scribe assist by
    Manu Sporny]
Dave Longley:  They shouldn't be surprised as they have to use
    the flag to generate them... it's off by default. It would be
    fine to mention it in the spec. [scribe assist by Manu Sporny]

PROPOSAL: Clarify the at-risk #10 feature in the specification by
    stating that if the use generalized RDF flag is set, then the
    toRDF algorithm could generate blank node properties.

Niklas Lindström:
    http://json-ld.org/spec/latest/json-ld/#at-risk-10
Dave Longley:  "Setting @base to null will prevent relative IRIs
    to be expanded to absolute IRIs." should be changed to "Setting
    @base to null will prevent relative IRIs from being expanded to
    absolute IRIs."
Manu Sporny: +1
Gregg Kellogg: +1
Gavin Carothers:  would that solve your need? [scribe assist by
    Niklas Lindström]
Dave Longley: +1
Markus Lanthaler:
    http://json-ld.org/spec/latest/json-ld/#base-iri
Gregg Kellogg: [[[A generalized RDF triple is an RDF triple
    generalized so that subjects, predicates, and objects are all
    allowed to be IRIs, blank nodes, or literals.]]]
Markus Lanthaler:
 
http://json-ld.org/spec/latest/json-ld-api/#deserialize-json-ld-to-rdf-algorithm
Markus Lanthaler: Step 4.3.1 always drops such nodes
Gregg Kellogg:  generalized RDF doesn't include relative IRIs
Dave Longley:  yeah, individual implementations could add a flag
    to keep relative IRIs

Topic: Candidate Recommendation Period

Markus Lanthaler: Upcoming Publishing Moratoria: the week
    starting 11 November during TPAC 2013 // starting 18 December
    2013 through 1 January 2014

PROPOSAL: The Candidate Recommendation period for JSON-LD is
    closed as of October 15th 2013.

Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +1

RESOLUTION: The Candidate Recommendation period for JSON-LD is
    closed as of October 15th 2013.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 15 October 2013 16:15:59 UTC