- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 15 Oct 2013 11:16:34 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
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:16:01 UTC