RDF Working Group Teleconference -- 11 Jul 2012

<trackbot> Date: 11 July 2012

<gavinc> 8am ... mmm... coffee

<scribe> scribenick: gkellogg

<davidwood> scribenick: gkellogg

<scribe> scribe: Gregg Kellogg

<davidwood> PROPOSED to accept the minutes of the 27 Jun telecon:

<davidwood> http://www.w3.org/2011/rdf-wg/meeting/2012-06-27

david: objections to accepting minutes?

RESOLVED to accept the minutes of the 27 Jun telecon

Action Items

<davidwood> http://www.w3.org/2011/rdf-wg/track/actions/pendingreview

<davidwood> http://www.w3.org/2011/rdf-wg/track/actions/open

david: no pending action items, but there are some open ones.

… action 176 for guus, but I see that it's done

<davidwood> closed action 176

… next telecon on July 25th

… I'll be on holiday, and Guus will be chairing.

Next FTF

… Peter is designated scribe, and piere-antoine alternate.

<davidwood> Poll results: https://www.w3.org/2002/09/wbs/46168/FTF-Fall2012/results

<davidwood> Mon-Tue 29-30 Oct, Lyon, France, co-located with TPAC.

<gavinc> There is no remote ability, is that correct?

david: will be able to meet with the Linked-Data Platform group, but no one else.

… we had two WGs to meet with, one LDP and Prov, but Prov isn't meeting at TPAC

sandro: prov meet collocated with ISWC

Turtle Last Call

<AndyS> Apologies for being late

<davidwood> What's left to do before publication request?

<davidwood> CfC: http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jul/0005.html

<davidwood> Editor's draft: http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html

<davidwood> However, the pub request has now been made

david: there were a couple of things remaining for Turtle LC, but pub-request has been made.

gavin: ED is not what was published.

<davidwood> http://www.w3.org/TR/turtle/

david: Eric put in a request to publish Turtle, which they did, but we didn't actually have formal approval from Thomas.

sandro: don't think we need approval.

<davidwood> Chairs message regarding the publication: http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jul/0014.html

david: I sent a message to Thomas and chairs that we're publishing.

sandro: need to tell chairs to get cross-domain review.

<davidwood> http://www.w3.org/TR/2012/WD-turtle-20120710/

<gavinc> http://www.w3.org/TR/turtle/

gavin: that's the URL which was published, pointed to by the TR link

david: will send message to chairs asking for broader review.

<sandro> not seeing any mention of Domain Lead in http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=lc-wd-tr

<sandro> (well, not in the critical path)

<scribe> ACTION: david to create blog post on swig blog for Turtle LC [recorded in http://www.w3.org/2012/07/11-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-177 - Create blog post on swig blog for Turtle LC [on David Wood - due 2012-07-18].

david: our charter requires feedback from certain other WGs

… Coordination, Internationalization, SPARQL, RDFa, XML Query

… Web Application WG

<gavinc> DOM, for us WAWG is about DOM

JSON-LD

david: Manu, can you give status on IPR?

<manu> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jul/0016.html

manu: we have all IPR commitments we need for JSON-LD Syntax and API Docs.

… I was waiting on an additional commitment from Josh Mandel, due to bug tracker activity.

… However, there is no content in docs related to his issue.

… We should try to get a commitment if we put in a new "objectify" API.

… I believe we have all the commitments we need from contributors who added content.

manu: we're good to go as far as IPR commitments are concerned.

… The discussion on the JSON-LD telco was that we're good to go.

… Docs are prepped to release as FPWD. Web Req is waiting for us to make a resolution.

<gavinc> Zakim who is here?

david: we've been saying for weeks that we're planning on publishing.

sandro: think's we're okay to announce.

manu: pub date is for tomorrow, as we've said for over a week.

<manu> PROPOSAL: The RDF Working Group believes that there are no IPR commitment issues for the JSON-LD Syntax and the JSON-LD API FPWDs. Publication should commence tomorrow - July 12th, 2012.

<gavinc> Also, the documents version control can be found at http://dvcs.w3.org/hg/json-ld/summary not in the rdf hg repository, in case anyone can't find them

<manu> PROPOSAL: The RDF Working Group resolves to publish the JSON-LD Syntax and the JSON-LD API specifications as FPWDs on July 12th, 2012.

<AndyS> It's in the minutes of June/27 meeting that the pub date is July 12

<manu> +1

<cgreer> +1

<davidwood> +1

<MacTed> +1

<mlnt> +1

<yvesr> +1

<sandro> +1

<AlexHall> +1

<gavinc> +1

<AndyS> and I wasn't at the meeting!

<AndyS> +1

<zwu2> +1

<AZ> +1

RESOLUTION: The RDF Working Group resolves to publish the JSON-LD Syntax and the JSON-LD API specifications as FPWDs on July 12th, 2012.

david: because these are FPWDs we will need to request from domain activity lead.

<AndyS> shortname?

manu: we already did that.
... we have short names picked out. All we need to do is hit publish button.
... The JSON-LD CG has been operating pretty smoothly on a separate telco. I presume we'll keep that telco going to save this group.

… I was thinking we'd keep that telco around and any work group members are welcome to join.

… The alternative is to try to merge the telecoms, but I'm afraid that the time commitment might be pretty steep.

… This leads to several 2-hour telecons to deal with API issues.

david: I've been involved in other groups with task-forces that met seprately.

… Any one in this group should be welcome to join. You've effectively changing from a CG to a task force of this group.

<AndyS> Suggestion ... JSON-LD changes (not API) go to the RDF-WG list because it's a wider group in CG. "Commit then review" (master doc is in RDF hg?)

manu: I think we need to be careful about how we get input in. We don't want to slow the group down by adding process, but if someone from the public joins this could create IPR issues.

… We could say that anyone that joins the call is automatically releasing any IPR, which may be enough to keep people away that have patent issues.

andy: if you're going to get people to sign in the call to grant IPR rights, you need and explicit step in an email, or something.

… E.G, signing into the Apache group says you're releasing rights.

<gavinc> +1 to explicit log of IPR commitment

… You need something outside of the call, just on the call might not be strong enough. They have to take an explicit step.

david: I agree with Andy, we need something equivalent.

manu: we've been running the calls on a separate VOIP server, which sends a message that gives people the opportunity to leave first.

andy: that's probably enough.

manu: we could just change the message to say that you're automatically releasing everything discussed on the call.

sandro: I don't know how you'd document that.

manu: that means that if someone joins the call that hasn't agreed to the IPR release, they must leave the call.

andy: need to do before their on the call, not after.

manu: we've been trying to not prevent people from joining the call.

… last week we had denny from WikiData join the call, and it was really helpful.

… we don't want to prevent those types of interactions.

ted: the big difference is that voice recording means there's no such thing as don't minute this.

manu: we wanted the process to be open. If they want it to be closed, they should join the RDF WG.

ted: recording may have an unintended consequence of silencing some input.

manu: large groups that might have a problem participating on the JSON-LD telco are represented on this call.

… so far, it doesn't seem to have been a problem.

<Zakim> AndyS, you wanted to say (A) need to get in legal checked and (B) it's "license of IP", not "release of IP"

andy: I'd be sure that you get this checked by W3C. Unwinding this could be a problem, as it's talking about licensing, not release. Reassignment of IPR is impossible, and blocked in some con tries.

manu: from this point on, we'll reject pull requests from non-WG members.

david: note that we have rdf-comments list for public input.

<gavinc> http://dvcs.w3.org/hg/json-ld/summary

manu: master of docs are on GitHub, but they're mirrored to mercurial.

andy: from a W3C point of view, I'd like to see it checked. Otherwise, you're committing stuff from GitHub to hg in W3C automatically.

<gavinc> AndyS, the author info stays the same between hg and git. UNLIKE git and svn

manu: we discussed with Ivan and Ian, who didn't raise issues.

andy: unless you have a paper trail to back pull requests, you're taking on a big responsibility.

… The copyright is between W3C and the reader of the spec.

manu: would this require a release for any kind of pull-request?

andy: it would be easier if you just use mercurial.

… it's a difference in licensing with the version control systems.

manu: the specs are part of the JSON-LD website, so that they're kept in sync.

<PatHayes> um...are we going to discuss any technical topics today or is it all legal discussions?

manu: commits are made by people who have made IPR commitments. All major changes made by WG members, other than David Lane, who is an employee of Digital Bazaar.

andy: there's a gap, you have commitments from people for what they had contributed, not what they're doing after.

… I think there's a missing step.

manu: I think there's only a gap if we allow a commit from someone who's not a WG member.

andy: if you make a commit of someone else's copyright, that creates a problem.

manu: specs are under W3C copyright, which says that original authors own content, but license it to W3C.

ted: it's a question of what happens when I put something else, where does it say that past stuff applies to what I'm doing now.

… The concern is for non-WG members.

manu: if a pull request isn't taken, an editor needs to make the request manually, just like if it had been received over rdf-comments.

andy: the difference is the step taken to send something into rdf-comments.

david: the only requirement the WG has is that we need to respond to their comments.

… Any member of the public can and should have the ability to comment through rdf-comments. That's different from participating in the group, for which they need to check a box.

ted: the submissions that come in through the source comments need to go through rdf-comments.

manu: we'll reject pull-requests, and redirect people through rdf-comments.

<PatHayes> makes sense to me.

sandro: I don't know how a pull request is any different than a public comment.

andy: there's a layer of indirection.

<gavinc> git does a damn good job of keeping track of the original author of each change

manu: a pull request is like a forward.

<AndyS> but puts in one unit (a pull request)

<gavinc> No.

<gavinc> Git doesn't do that.

ted: is the attribution kept forever? If the chain of origin is maintained.

<gavinc> The merge commit keeps track of the original commits

andy: this is a difference between centralized and distributed.

<sandro> sandro: how about rejecting any pull request not from the person who made all the changes?

<gavinc> It works in Linux!

manu: we'll just reject all requests to change the spec by non-RDF group members.

<sandro> andy: as long as that policy is set and made public.

andy: it would be good to get this to work, as these are the tools of the future.

… Linux situation is fundamentally different.

manu: perhaps W3C would need to modify copyright license to make it work as if it's GPL.

gavin: as andy pointed out, the W3C license situation is pretty strange.

manu: that copyright is not the same as the final CG copyright.

<manu> Copyright © 2010-2012 the Contributors to the JSON-LD Syntax 1.0 Specification, published by the JSON for Linking Data Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.

andy: the issue is what happens going forward.

gavin: I think the JSON-LD license is different than Turtle.

sandro: no, that won't get past pub-rules.

<sandro> (I think!)

manu: for now, we'll just reject any pull request until we figure out the right way to do this.

<sandro> sandro: and all the current authors have transfered copyright to W3C?

<Zakim> AndyS, you wanted to ask (after the current discussion point) about WG-CG involvement and suggest a "Commit then review" model.

… All contributors have signed IPR agreements.

andy: how to the WG and the CG work together.

<sandro> manu: They've signed the IPR agreements which I believe does that.

david: we should say that anyone that's not a WG member is free to comment on rdf-comments.

manu: is it okay for company employees to make commits?

sandro: should put them in the WG.

<gavinc> Or join the W3C as a company ;)

david: the syntax and API specs are moving to the RDF WG, and the individual members of the CG that will work on it should move to the RDF WG and effectively form a Task Force.

… That TF can have a separate telecon, coincident with the telecon.

… The CG can work on documents that don't bear on the Syntax and API docs.

<PatHayes> Pat has to leave. apologies for being late.

david: the CG should not work on the syntax or API docs.

manu: can we talk about them? (yes)

david: conceptually, think of the Syntax and API as operating through the WG.

andy: there are two ways that such projects work: commit then review, or review and then commit,

… I suggest commit then review and let the WG know about any non-editorial changes.

… commit then review works better for small groups.

manu: we will send an email out with plain english, rather than raw commit messages or diffs.
... don't expect massive re-engineering of the spec.

AOB

gavin: now getting started on WG of N-Triples.

… want to figure out if we want to specify canonical form of N-Triples.

… This is broken into how a specific triple is canonicalized.

… The second problem is how to do it for a graph. The answer to that is probably no for all graphs, but there is a subset for which it can.

manu: we're very interested in this problem and think we have a solution.

… we have a solution using N-Quads. We haven't yet found a graph for which the algorithm doesn't work, but it might not finish.

… All real-world problems have worked to date, other than complexity.

gavin: start with triple canonicalization, follow with graphs.

manu: would prefer to talk about quads.

andy: blank nodes are the issue.

<manu> http://json-ld.org/playground/

gavin: if we do triples, the extension to quads is straight-forward.

manu: there's an implementation in the playground.

… we have specs on normalization, but can't sign up to edit N-Triples at this point.

<AndyS> What is the use case for a canonical order of triples or quads?

<gavinc> Signing :D

manu: digital signatures are needed for items for sale.

… We take the offer and canonicalize/normalize to sign it.

… Also useful to make statements about other transactions.

… we sign the byte-stream of the canonicalized n-quads.

andy: other way is to maintain a master copy and rely on that not changing.

manu: putting N-Quads in a web message is a problem.

… these digital contracts are unique for each individually buyer.

<zwu2> has to leave for another meeting

<zwu2> bye

<Zakim> sandro, you wanted to ask how we're handling normative references from Turtle to RDF11 Concepts?

<gavinc> Screwed up and didn't refrence it.

sandro: there's not normative reference from RDF Concepts to Turtle.

<AndyS> ?? Fix at at PR.

gavin: we reference 1.0, not 1.1. This is a problem.

… need 1.1, as 1.0 doesn't refer to IRI.

sandro: we can refer to IRI separately.

david: XSD or some other spec references an upcoming version or a future release.

… It may be some other W3C spec.

gavin: norm ref needs to be to RDF Concepts 1.1

sandro: Concepts will probably be stuck on other docs, such as semantics.

andy: you can advance close to Rec without the others being resolved.

- DRAFT -

RDF Working Group Teleconference

11 Jul 2012

Attendees

Contents

Action Items

Next FTF

Turtle Last Call

JSON-LD

AOB

Summary of Action Items

Scribe.perl diagnostic output