Chatlog 2012-05-30

See panel, original RRSAgent log or preview nicely formatted version.

Please justify/explain non-obvious edits to this page, in your "edit summary" text.

14:15:27 <RRSAgent> RRSAgent has joined #rdf-wg
14:15:27 <RRSAgent> logging to http://www.w3.org/2012/05/30-rdf-wg-irc
14:15:29 <trackbot> RRSAgent, make logs world
14:15:29 <Zakim> Zakim has joined #rdf-wg
14:15:31 <trackbot> Zakim, this will be 73394
14:15:31 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 45 minutes
14:15:32 <trackbot> Meeting: RDF Working Group Teleconference
14:15:32 <trackbot> Date: 30 May 2012
14:20:06 <gavinc> gavinc has joined #rdf-wg
14:39:05 <AndyS1> AndyS1 has joined #rdf-wg
14:51:59 <Zakim> SW_RDFWG()11:00AM has now started
14:52:06 <Zakim> +Guus
14:52:20 <Guus> Guus has joined #rdf-wg
14:55:00 <cygri> cygri has joined #rdf-wg
14:58:12 <tbaker> tbaker has joined #rdf-wg
14:58:17 <ivan> zakim, dial ivan-voip
14:58:17 <Zakim> ok, ivan; the call is being made
14:58:18 <Zakim> +Ivan
14:58:49 <Zakim> +??P3
14:58:56 <AndyS> zakim, ??P3 is me
14:58:56 <Zakim> +AndyS; got it
14:59:10 <Zakim> +bhyland
14:59:42 <davidwood> Zakim, who is talking?
14:59:52 <davidwood> Zakim, bhyland is me
14:59:52 <Zakim> +davidwood; got it
14:59:54 <Zakim> davidwood, listening for 10 seconds I heard sound from the following: AndyS (56%)
14:59:57 <Zakim> +??P6
15:00:02 <pchampin> pchampin has joined #rdf-wg
15:00:02 <gkellogg> zakim, I am ??P6
15:00:02 <Zakim> +gkellogg; got it
15:00:11 <Zakim> +Sandro
15:00:15 <pfps> pfps has joined #rdf-wg
15:00:50 <Zakim> +[IBM]
15:00:54 <manu1> zakim, code?
15:00:54 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), manu1
15:01:05 <AZ> AZ has joined #rdf-wg
15:01:05 <pfps> zakim, [IBM] is temporarily me
15:01:05 <Zakim> +pfps; got it
15:01:08 <Zakim> +??P10
15:01:11 <Zakim> +??P8
15:01:15 <manu1> zakim, I am ??P10
15:01:15 <Zakim> +Tom_Baker (was ??P8)
15:01:16 <Zakim> +manu1; got it
15:01:41 <Zakim> +mhausenblas
15:01:43 <cygri> zakim, mhausenblas is temporarily me
15:01:43 <Zakim> +cygri; got it
15:03:02 <Zakim> +??P17
15:03:06 <Zakim> -AndyS
15:03:21 <AZ> zakim, ??P17 is me
15:03:21 <Zakim> +AZ; got it
15:03:25 <Zakim> +??P3
15:03:31 <AndyS> zakim, ??P3 is me
15:03:31 <Zakim> +AndyS; got it
15:04:08 <AlexHall> AlexHall has joined #rdf-wg
15:04:17 <Zakim> + +1.443.212.aaaa
15:04:21 <manu1> scribenick: manu1
15:04:25 <AlexHall> zakim, aaaa is me
15:04:25 <Zakim> +AlexHall; got it
15:04:53 <manu1> Topic: Minutes from Last Meeting
15:05:08 <cygri>  http://www.w3.org/2011/rdf-wg/meeting/2012-05-23
15:05:10 <manu1> Guus: Here they are: http://www.w3.org/2011/rdf-wg/meeting/2012-05-23
15:05:27 <manu1> PROPOSAL: Accept the minutes of the 23 May telecon.
15:05:46 <Zakim> +gavinc
15:05:58 <manu1> Sandro: Errors in the minutes... should fix those before we accept them.
15:05:59 <zwu2> zwu2 has joined #rdf-wg
15:06:04 <zwu2> zakim, code?
15:06:04 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), zwu2
15:06:34 <pfps> The only problem with the minutes appears to be a confusion about who Tony is.
15:06:44 <manu1> s/Sandro: Errors in the minutes/davidwood: Errors in the minutes/
15:06:56 <manu1> Guus: These are not big issues in the minutes, happy to take an action to fix them.
15:07:00 <cygri> +1
15:07:11 <manu1> RESOLVED: Accept the minutes of the 23 May telecon.
15:07:12 <pfps> +1
15:07:12 <Zakim> +zwu2
15:07:17 <zwu2> zakim, mute me
15:07:17 <Zakim> zwu2 should now be muted
15:07:24 <Zakim> +OpenLink_Software
15:07:24 <manu1> No objections for resolving minutes.
15:07:32 <MacTed> Zakim, OpenLink_Software is temporarily me
15:07:32 <Zakim> +MacTed; got it
15:07:33 <MacTed> Zakim, mute me
15:07:33 <Zakim> MacTed should now be muted
15:07:40 <manu1> Guus looking at action items to see if we can get rid of anything...
15:08:08 <manu1> davidwood: I went through all the folks that attended telecons, only pulled scribes who showed up in 2012.
15:08:29 <manu1> Guus: Welcome Gregg Kellogg!
15:08:41 <cygri> welcome gkellogg!
15:09:04 <manu1> Guus: Virtual round of applause for Peter, who just became an IEEE Fellow!
15:09:08 <manu1> *clapping*
15:09:32 <manu1> Guus: Richard, claiming victory on your two actions? 173 174?
15:09:50 <manu1> Richard: Yes, conformance section for TURTLE is good. Second action - wrote mail to Yves, but didn't get a response yet.
15:09:58 <manu1> Guus: Yes, but you did the action... so that's good.
15:10:54 <manu1> Topic: Next Meeting
15:11:14 <manu1> Guus: Next week is SemTech 2012 - I'm not available for chairing. Let's skip next week.
15:11:18 <manu1> DavidWood: I concur.
15:11:37 <manu1> No objections... resolved that next telecon is June 13th 2012.
15:11:56 <manu1> Topic: Turtle Last Call
15:12:02 <manu1>  http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html
15:12:09 <manu1> Guus: Is there additional action on this needed?
15:12:12 <Zakim> +??P29
15:12:13 <Guus> zakim, who is here?
15:12:14 <Zakim> On the phone I see Guus, Ivan, davidwood, gkellogg, Sandro, pfps, manu1, Tom_Baker, cygri, AZ, AndyS, AlexHall, gavinc, zwu2 (muted), MacTed (muted), ??P29
15:12:14 <Zakim> On IRC I see zwu2, AlexHall, AZ, pfps, pchampin, tbaker, cygri, Guus, gavinc, Zakim, RRSAgent, swh, AndyS, MacTed, mischat, LeeF, ivan, davidwood, gkellogg, manu1, trackbot, NickH,
15:12:15 <Zakim> ... manu, sandro, ericP
15:12:20 <pchampin> zakim, ??P29 is me
15:12:20 <Zakim> +pchampin; got it
15:12:37 <manu1> gavinc: Nothing to raise as an issue, it's not quite done.
15:13:05 <manu1> Guus: You get one more week since SemTech 2012 is next week. We'll schedule TURTLE LC decision until June 13th 2012. But nothing to discuss now, right?
15:13:10 <pchampin> q+ about reviewing turtle
15:13:16 <pchampin> q+ to ask about reviewing turtle
15:13:25 <manu1> Gavin: There is a recurring discussion on should we have the Turtle family of languages?
15:14:20 <manu1> pchampin: I have a pending action to review the Turtle document - I've been told to wait until some mods are done. I may have missed something, but I haven't been prompted to review yet. Should I do it before next meeting?
15:14:32 <manu1> Guus: I think the documents have plenty of review - you could do a check at this point.
15:14:47 <manu1> Guus: Editor's are doing final editorial changes now.
15:14:58 <manu1> pchampin: Sorry I missed the opportunity, I will do a check on the documents.
15:15:25 <manu1> Guus: Ok, we're fine to go ahead then, Gavin.
15:15:35 <manu1> Topic: JSON-LD
15:15:42 <manu1> http://lists.w3.org/Archives/Public/public-rdf-comments/2012May/0070.html
15:15:46 <Zakim> +??P31
15:15:57 <swh> Zakim, ??P31 is me
15:15:57 <Zakim> +swh; got it
15:16:12 <manu1> http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0635.html
15:16:28 <cygri> scribenick: cygri
15:16:50 <cygri> manu: proposal to publish JSON-LD as FPWD is here: http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0635.html
15:17:10 <cygri> ... some RDF-WG members joined the previous JSON-LD call to discuss some issues
15:17:36 <cygri> ... such as, what spec should the to/from-RDF-algorithm go, should the API spec go to W3C or not, should experimental stuff go in or not
15:17:48 <cygri> ... i feel we got consensus
15:18:01 <Zakim> +EricP
15:18:07 <cygri> ... i'd like to summarize main points
15:19:05 <cygri> ... 1. should JSON-LD terminology be made more in line with RDF concepts? we think yes where it makes sense, but there are some minor corner cases where we feel our terminology is more appropriate. this shouldn't block FPWD
15:19:20 <Zakim> -EricP
15:19:27 <gavinc> Yes.
15:19:27 <Zakim> +EricP
15:19:33 <gavinc> It should be in the document
15:19:39 <gavinc> So that the public knows
15:19:42 <cygri> EricP: is it worth noting that in the document?
15:20:00 <gavinc> <p class="issue"></p>
15:20:34 <cygri> manu: we have it documented it in various places, minutes etc
15:20:48 <cygri> ericP: an issue marker in the doc would be great
15:20:53 <manu1> https://github.com/json-ld/json-ld.org/issues/127
15:21:29 <cygri> davidwood: also note that rdf-concepts is still a somewhat moving target
15:21:57 <Zakim> -zwu2
15:22:10 <cygri> manu: 2. we think the RDF-WG should also publish the JSON-LD API spec because it has the algorithms for converting to and from RDF
15:22:21 <cygri> ... these algorithms are in the JSON-LD API spec at the moment
15:22:27 <Guus> zakim, who is here?
15:22:27 <Zakim> On the phone I see Guus, Ivan, davidwood, gkellogg, Sandro, pfps, manu1, Tom_Baker, cygri, AZ, AndyS, AlexHall, gavinc, MacTed (muted), pchampin, swh, EricP
15:22:30 <Zakim> On IRC I see zwu2, AlexHall, AZ, pfps, pchampin, tbaker, cygri, Guus, gavinc, Zakim, RRSAgent, swh, AndyS, MacTed, mischat, LeeF, ivan, davidwood, gkellogg, manu1, trackbot, NickH,
15:22:30 <Zakim> ... manu, sandro, ericP
15:22:40 <cygri> ... we could have lifted the algorithms from the spec, but this would be weird editorially
15:22:53 <Zakim> + +1.603.438.aabb
15:23:12 <zwu2> zakim, +1.603.438.aabb is me
15:23:12 <Zakim> +zwu2; got it
15:23:22 <Guus> q?
15:23:28 <Guus> ack pchampin
15:23:28 <Zakim> pchampin, you wanted to ask about reviewing turtle
15:23:35 <cygri> ... another option would be to have the conversion algorithm in its own separate document, but concluded that the API spec is fine as it is; just remove some experimental bits
15:23:58 <ericP> i added a comment at the botton of <https://github.com/json-ld/json-ld.org/issues/127#issuecomment-6012736> saying "In a prominent place in the FPWD, document the intention to align with the RDF model and terminology. This will calm the RDF community and reduce the comments requesting something you already plan to do."
15:24:01 <cygri> ... an open question is: can the RDF-WG publish an API spec for JSON-LD, charter-wise?
15:24:21 <cygri> ... we think yes because it supports the syntax spec; they go together and complement one another
15:24:28 <PatH> PatH has joined #rdf-wg
15:24:39 <PatH> Sorry Im late, and IRC only.
15:24:45 <cygri> ... so baring objections from W3C members we think it should be ok
15:25:33 <cygri> manu: 3. having established that RDF-WG *can* publish JSON-LD API, *should* it do it?
15:25:48 <cygri> ... we need to pull some bits out of the spec
15:25:58 <cygri> ... graph normalization is already moved into its own separate document
15:26:06 <cygri> ... and we'll also remove framing 
15:26:20 <cygri> ... because these are experimental features; the rest is stable enough for FPWD
15:27:03 <cygri> ... so in summary we think RDF-WG should publish JSON-LD API as this pulls in the normative conversion, and is a useful spec
15:27:23 <cygri> 4. should we move the to/from-RDF stuff into separate document?
15:27:30 <cygri> manu: 4. should we move the to/from-RDF stuff into separate document?
15:27:33 <cygri> ... no, no need to
15:27:55 <cygri> manu: 5. how to do the handover of JSON-LD specs from the community group to RDF-WG
15:28:03 <cygri> ... there's W3C process for that
15:28:15 <cygri> ... so a hand-off can be done once RDF-WG has made a decision
15:28:37 <gavinc> +q assignment of editors for JSON-LD in the WG
15:28:39 <cygri> ... once the hand-off is done, RDF-WG is in charge of the docs and the CG can't change it any more
15:28:45 <gavinc> +q to ask about assignment of editors for JSON-LD in the WG
15:28:50 <cygri> ... this entails copyright and patent stuff etc
15:28:52 <AndyS> q+ to ask about handoff point @LC? @CR?
15:29:30 <cygri> manu: so the proposal is that RDF-WG publish JSON-LD syntax spec *and* stripped-down version of JSON-LD API spec with framing and normalization removed, as FPWD 
15:29:33 <davidwood> q+ to ask about number of implementations
15:29:44 <Guus> ack gavinc
15:29:44 <Zakim> gavinc, you wanted to ask about assignment of editors for JSON-LD in the WG
15:29:52 <Guus> ack AndyS
15:29:52 <Zakim> AndyS, you wanted to ask about handoff point @LC? @CR?
15:29:56 <cygri> AndyS: what state would documents be in after the hand-off?
15:30:24 <cygri> manu: FPWD. the community group says "we are done with these documents", and the WG pulls them in as FPWDs
15:30:38 <cygri> ... it's up to the WG to decide how quickly the docs can go to LC
15:31:00 <cygri> guus: whether they are rec track is still a separate decision
15:31:00 <ivan> ivan has left #rdf-wg
15:31:57 <cygri> manu: the CG would have an issue handing off the documents if RDF-WG doesn't take them to REC. CG would likely try to find another venue in that case
15:32:13 <cygri> AndyS: hoping that CG would continue to be involved all the way to REC
15:32:19 <Guus> ack davidwood
15:32:19 <Zakim> davidwood, you wanted to ask about number of implementations
15:32:26 <gavinc> +q to ask about assignment of editors for JSON-LD in the WG
15:32:36 <cygri> manu: yes that's the plan. that's why gkellogg is joining and the other editors will become invited experts
15:32:47 <gkellogg> Immplementations link here: http://json-ld.org/
15:32:51 <cygri> manu: there are (numerous implementations)
15:33:07 <cygri> ... six implementationsj
15:33:19 <cygri> ericP: i might have written a parser too. i forget.
15:33:38 <cygri> ivan: i have JSON-LD output in my RDFa impl
15:33:39 <Guus> ack gavinc
15:33:39 <Zakim> gavinc, you wanted to ask about assignment of editors for JSON-LD in the WG
15:34:23 <cygri> gavinc: do we get editors assigned to the JSON-LD docs before FPWD?
15:34:56 <cygri> manu: when the group decides to take the docs on as rec track work, the current editors will join RDF-WG
15:35:24 <ericP> +1 to rec track
15:35:33 <pchampin> +1 to rec track
15:35:36 <cygri> guus: opinions on taking JSON-LD on rec track?
15:35:37 <gkellogg> +1
15:35:39 <manu1> +1 to rec track (fwiw)
15:35:43 <cygri> ... JSOn syntax in the charter
15:35:44 <PatH> +1
15:35:56 <sandro> +0.5 I'm nervous about the lack of breadth of input
15:36:01 <gavinc> +0 (TQ non opinion) +1 (LexMachina opinion which I can't have until July)
15:36:04 <ericP> q?
15:36:04 <cygri> davidwood: what was the plan re the RDF algorithm, can't recall 
15:36:33 <PatH> Gavin is a quantum superposition.
15:36:50 <AndyS> 0 (I can't promise my time to it so don't feel I can +1) -- moral +1 to JSON-LD/RDF core parts
15:36:52 <cygri> ivan: we talked about possibly publishing the JSON-LD group's graph normalization algorithm separately as a note
15:36:54 <davidwood> +1
15:37:01 <ivan> ivan has joined #rdf-wg
15:37:04 <zwu2> +0
15:37:31 <Guus> q?
15:38:18 <manu1> q+ to explain the breadth of review.
15:38:19 <cygri> sandro: JSON-LD is the product of a small group of people. it's in our charter, so the world was put on notice, but i think not all people who are concerned about this are involved
15:38:22 <gavinc> FPWD will need a lot of review
15:38:34 <gkellogg> q+
15:38:36 <cygri> ... if we don't get the right people involved in reviewing, it would be a problem
15:38:54 <cygri> ... don't want it to go to rec just because a few people like it and the rest don't pay attention
15:39:43 <cygri> ... can we get enough people who know what a good json api looks like to review this?
15:40:02 <cygri> manu: to be clear, there were four editors, but the spec has been passed by a number of other communities
15:40:33 <Guus> q+
15:40:34 <cygri> ... markus has a list of users
15:40:39 <Guus> ack manu1
15:40:39 <Zakim> manu1, you wanted to explain the breadth of review.
15:41:17 <cygri> ... you could say that for any spec. there's not just the people who show up to the telcos
15:41:30 <cygri> ... it has had more review than ppl in RDF-WG may think
15:41:54 <cygri> guus: it would be good if that was visible from the documents
15:42:01 <cygri> q+
15:42:17 <cygri> sandro: that could be mentioned in the status section of the document
15:42:32 <sandro> best to start maintinaing an Implement Report page.
15:42:37 <Guus> ack gkellogg
15:42:39 <sandro> best to start maintinaing an Implementation Report page.
15:42:54 <cygri> gkellogg: dbpedia has json-ld format output for example
15:43:02 <manu1> Sandro, implementations are listed on the front page of http://json-ld.org/
15:43:16 <cygri> ... comparing rdfa and json-ld, they have received similar amount of input
15:43:27 <gkellogg> http://www.slideshare.net/lanthaler/jsonld-for-restful-services
15:43:33 <cygri> ... btw i'm giving a talk at semtech on json-ld
15:43:41 <cygri> ... it includes list of implementations
15:44:06 <PatH> Richard, got a link to that talk? Slides?
15:44:22 <cygri> PatH, http://www.slideshare.net/lanthaler/jsonld-for-restful-services
15:44:25 <PatH> Ta.
15:44:51 <cygri> guus: it's important to get public comments on this entire issue
15:45:38 <Guus> ack Guus
15:45:46 <Guus> ack cygri
15:46:00 <manu1> cygri: Guus, you said that you might want to be able to tell if it's gotten more public feedback?
15:46:34 <manu1> cygri: Sandro already mentioned that it might go into the status of the document section - even though this is a FPWD, it already has an 18-month history elsewhere.
15:46:45 <manu1> cygri: We should state this clearly in the status section.
15:47:01 <Guus> q?
15:47:07 <cygri> manu: we have a number of document cleanup issues, i'll add it there
15:47:59 <cygri> PROPOSAL: RDF-WG to publish JSON-LD syntax spec, and stripped-down version of JSON-LD API spec with framing and normalization removed, as FPWD, with intention to go on recommendation track
15:48:10 <manu1> +1
15:48:11 <PatH> +1
15:48:12 <gkellogg> +1
15:48:13 <pfps> +1
15:48:16 <cygri> cygri: +1
15:48:19 <zwu2> +0
15:48:21 <Guus> +1
15:48:21 <AlexHall> +1
15:48:21 <pchampin> +1
15:48:23 <davidwood> +1
15:48:27 <sandro> +1
15:48:29 <ericP> +1
15:48:32 <gavinc> +0 (TQ) +1 (LexMachina non Member)
15:48:36 <ivan> +1
15:48:52 <cygri> RESOLVED:  RDF-WG to publish JSON-LD syntax spec, and stripped-down version of JSON-LD API spec with framing and normalization removed, as FPWD, with intention to go on recommendation track
15:48:59 <tbaker> +0
15:49:21 <cygri> guus: i think this will be very useful output for this group
15:49:27 <mischat> mischat has joined #rdf-wg
15:49:30 <cygri> manu: we will go back and apply all the changes we said
15:49:37 <cygri> ... we'll get the CG to sign off on those documents
15:49:49 <cygri> ... and then put them into W3C FPWD format and give them to the group
15:50:17 <cygri> guus: then there'll be a two-week review period before FPWD
15:50:30 <cygri> manu: i guess we should pull the trigger and get started on the transition
15:50:31 <ivan> q+
15:51:04 <cygri> ivan: the documents should physically move into the WG's hg repository
15:51:42 <cygri> guus: manu, you and gkellogg are WG members now. is markus the other critical person?
15:51:55 <gkellogg> I'd suggest niklasl as well.
15:52:10 <cygri> manu: yes; our CEO has also worked on a lot of the algorithms but may not be necessary to make him WG member
15:52:35 <cygri> gkellogg: niklasl is very vocal and has given good input too
15:52:52 <cygri> guus: does markus work for a W3C member?
15:53:04 <cygri> ... needs to be worked out
15:53:33 <cygri> ... manu, are you familiar with our hg repository?
15:53:56 <cygri> manu: there are some technical issues there but we'll iron those out
15:54:14 <cygri> q+
15:54:22 <Guus> ack ivan
15:54:30 <Guus> ack gygri
15:54:48 <ericP> i'm not convinced that it's worth making manu copy this across
15:54:54 <ericP> (and keep it in sync)
15:54:55 <manu1> cygri: I don't think it makes much sense to move it to W3C - as long as it's in a public repo, you can make your own copy and modify it.
15:55:21 <manu1> cygri: I don't have an objection with moving into mercurial repository - it's a process point, not a point of making sure everyone has adequate access - that's already true with github.
15:55:40 <AndyS> On IP and copyright front, surely move to W3C is cleaner.
15:55:44 <cygri> guus: it's good for clarity if everyting is in the same place
15:55:59 <AndyS> (its work though :-()
15:56:00 <manu1> +1 to AndyS - that's the strongest point, imho.
15:56:12 <pchampin> I guess the changes on mercurial could be mirrored on github if we want
15:56:16 <cygri> guus: thanks manu and gregg for bringing this to the WG
15:56:27 <cygri> ... are there potential reviewers?
15:56:42 <manu1> scribenick: manu1
15:56:48 <cygri> ... timeframe second part of june, early july
15:56:53 <manu1> EricP: I'd want to do a review.
15:57:00 <manu1> AndyS: I'd be interested...
15:57:07 <manu1> pchampin: I'd be interested in reviewing.
15:57:24 <manu1> Guus: We have 3 reviewers, that's good news.
15:57:26 <Zakim> +LeeF
15:57:36 <AndyS> s/interested/interested if time at the time/
15:57:56 <manu1> Topic: RDF spaces draft
15:58:27 <manu1> Guus: Should we discuss this document yet?
15:58:36 <manu1> Sandro: Probably a good as time as any to discuss it...
15:58:52 <manu1> Sandro: We may want to look at some of the other issues that we may have consensus on.
15:58:52 <cygri> q+
15:59:06 <manu1> Guus: Given the time, I'd prefer to do this on June 13th.
15:59:26 <Guus> ack cygri
15:59:33 <manu1> Richard: I think it might be useful to look at where we are from a high-level POV regarding the Graphs discussion. We have made some progress consolidating this fluid design space a bit.
15:59:58 <sandro> all the GRAPHS issues http://www.w3.org/2011/rdf-wg/track/products/1
15:59:59 <manu1> Richard: There are 3 open questions that can be treated separately - one of them is the terminology question - should we call this Graph Containers, Spaces, Stateful Resources, etc.
16:00:11 <ericP> +1 to graph space container resources
16:00:16 <Guus> +1 on the consensus on basic structure
16:00:18 <PatH> I suggest putting terminology last. 
16:00:19 <manu1> Richard: Despite a lot of disagreement, we seem to be talking about the same basic structure - it's mostly a matter of finding terms/definitions.
16:00:28 <Guus> +1 to Pat
16:00:54 <manu1> Richard: The second thing is the semantics - what we need to define about it to give it formal semantics - the good news is that we have a couple of proposals on the table.
16:01:08 <manu1> Richard: There are a number of sketches on how to do this... we may be able to work out what the options are from those.
16:01:21 <PatH> I don't see the convergence of ideas that Richard apparently sees. NOt yet, anyway.
16:01:23 <MacTed> ericP - I think you meant "stateful graph data space container resources"
16:02:03 <manu1> Richard: The third part is the syntax - seems like there are quite a number of open questions there - still lots of things to be talked about. We should clarify the open questions - the decisions that need to be made. N-Quads, TRiG, etc. We can treat these questions separately. Not everyone is interested in each of those discussions - we can have them in parallel.
16:02:10 <manu1> Guus: In the third part, you really meant syntax?
16:02:26 <sandro> q+
16:02:38 <LeeF> There are significant proposals for combining Turtle + TriG
16:02:40 <manu1> Guus: We never really seem to want a new syntax - proposals for adding a few RDF Classes or properties - not addition of new syntax, no?
16:02:40 <LeeF> that sort of thing
16:02:50 <gavinc> There are very large number of details ;)
16:02:53 <PatH> +1 to separation of semantics and syntax. 
16:03:03 <sandro> q-
16:03:09 <manu1> Richard: There is a question on whether N-Quads or TRiG should just be an extra feature for Turtle - not radical new proposals, but still questions that need to be answered.
16:03:18 <Guus> ack sandro
16:03:50 <manu1> Sandro: The most pointed concern is that TRiG is disjoint from Turtle - I think it's important to make curly braces optional, not a trivial syntax point at all.
16:04:33 <manu1> Sandro: We made some progress with g-* terminology - maybe we should use that?
16:05:24 <sandro> graph, graphState, containsGraph
16:05:29 <manu1> Guus: We should keep to placeholder terminology...
16:05:29 <sandro> containTriples
16:05:37 <sandro> g-rel
16:05:44 <cygri> g-rel +1
16:05:59 <cygri> also useful: g-pair
16:06:00 <MacTed> g-rel, g-rev ?  but which is which?
16:06:02 <manu1> Discussion about terminology
16:06:19 <PatH> Might be best to avoid the "contain" metaphor. We could just say hasGraph, hasTriples, etc..
16:06:21 <zwu2> go to jump to another meeting.
16:06:27 <MacTed> Zakim, unmute me
16:06:27 <Zakim> MacTed should no longer be muted
16:06:28 <zwu2> bye guys
16:06:29 <tbaker> +1 g-relation
16:06:35 <AndyS> Is there one fixed relationship?  Major decision.
16:06:50 <Zakim> -zwu2
16:06:56 <Zakim> -pfps
16:06:57 <manu1> Sandro: We want to get this temporary terminology correct so we don't get confused about it.
16:07:09 <sandro> I like g-contains
16:07:12 <pchampin> was about to propose g-state
16:07:19 <ericP> gbox2gstate
16:07:19 <cygri> then g-state
16:07:26 <ericP> gbox2gbox
16:07:33 <AndyS> q+
16:07:36 <ericP> gbox2gsnap rather
16:07:39 <PatH> Reading this on IRC, I am g-confused. 
16:07:56 <manu1> Sandro: We are talking about the relationship between a gBox and a gSnap.... 
16:08:03 <PatH> Ah, OK.
16:08:31 <manu1> Andy: This gets back to trying to sort out semantics... we are going down a particular route here - there is another level of indirection here.
16:08:33 <PatH> Its really between a gBox and a gSnap *and a time*.
16:08:47 <cygri> PatH +1
16:08:48 <manu1> Andy: The various different ways and use cases we've seen say that we're constraining this.
16:09:01 <PatH> Or more generally a particular set of circumstances defining an access event.
16:09:02 <manu1> Sandro: Sounds like we don't even have consensus about this point.
16:09:26 <ericP> i agree that there is a description of the use in addition to the mapping from gbox to gsnap
16:09:38 <cygri> q+ to say this is why i tried to argue against g-box
16:09:49 <manu1> Andy: The relationship between the URI and the graph has at one point... two steps... degree of flexibility for use cases. If we were flexible, that's what a gBox is... by going down to terminology now, we might be covering up an important discussion.
16:09:56 <manu1> Sandro: Are you suggesting we can't have a placeholder?
16:10:04 <manu1> Andy: Depends on what that placeholder is doing.
16:10:25 <Guus> q?
16:10:32 <Guus> ack AndyS
16:10:32 <manu1> Sandro: Placeholder for the name between the gBox and gSnap - what it has to do with the Web is not clear.
16:11:18 <Guus> q+
16:11:20 <manu1> Richard: This thing that we're talking about right now - is there really just one relationship - or does a different use case have a different relationship. This container metaphor with gBox is not such a good idea - it's stifling, makes it hard to think about this in terms that are sufficiently flexible.
16:11:24 <Guus> ack cygri
16:11:24 <Zakim> cygri, you wanted to say this is why i tried to argue against g-box
16:12:21 <manu1> Richard: I propose we say: Yes, there is only a single relationship - but we should put very little constraints on what could be a gBox. If any resource can be a gBox, then it's okay to have a single relationship to the gSnap because the flexibility is already in the fact that the graph IRI can be used to name anything.
16:12:29 <MacTed> saying "anything can be a gbox" seems like saying "anything can be a milk carton"... and that's not the case
16:12:38 <Guus> +1 to take this flexible view on what g-box stands for
16:12:46 <manu1> Richard: I think a single relationship is enough - if we don't take the gBox too literally, something very wide - then we're good (maybe)
16:13:18 <pchampin> q+
16:13:21 <manu1> Guus: I agree fully with the "flexible" point of view - taking all of this flexibility into account when trying to explain it, makes it more complex to outsiders. gBox may not always be the right metaphor.
16:13:31 <Guus> ack Guus
16:14:19 <Guus> Suggest to go for g-relation, could be multiple
16:14:29 <manu1> pchampin: I'm not sure I understand your point, Richard. If a gBox is restrained to be something very specific - a placeholder containing one graph at one point in time, when that might be okay. If you want to say that it's more flexible, there can be many possible relations between gBox to gSNap. I'd have exactly the opposite reasoning that you proposed.
16:14:30 <Guus> because of simplicity
16:15:02 <sandro> q+
16:15:04 <manu1> Richard: The flexibility is needed because one of the things that we need to be able to express in this abstract syntax is SPARQL. We can already associated an IRI with a graph - there are no constraints on the graph name.
16:15:12 <manu1> q+ to discuss JSON-LD named graphs and what IRI identifies.
16:15:29 <manu1> Richard: This flexibility needs to be in the model as well.
16:15:50 <manu1> Richard: This may be better done in written form than in discussion.
16:16:05 <MacTed> q+
16:16:10 <manu1> pchampin: You consider the URI as a part of the gBox... but I don't consider the URI as a part of the gBox.
16:16:30 <PatH> We can get into g-box metaphysics and never get back out. Semantic lesson is, it doesnt matter unless it affects a truthvalue of some triple. 
16:17:02 <sandro> q+ to talk about the person-as-graph-name use case
16:17:02 <manu1> Richard: as long as we don't take a strong stance on what the IRI denotes, we're good. If we say the IRI denotes a gBox, then that sounds fine, but it's difficult to see how an IRI can denote a person.
16:17:23 <pchampin> thanks Richard, it makes more sense to me now
16:17:26 <manu1> Sandro: can we adjourn the meeting and graph people stay on and chat.
16:17:40 <manu1> Guus: We don't have a placeholder name for the relationship.
16:18:11 <Zakim> -Ivan
16:18:11 <manu1> Guus: meeting adjourned.
16:18:18 <sandro> q?
16:18:20 <Zakim> -swh
16:18:22 <Zakim> -gavinc
16:18:23 <Zakim> -AlexHall
16:18:24 <MacTed> q+ to suggest that SPARQL is actually (quantumly?)addressing gSnaps, not gBoxes, even if the gSnap is not persistent
16:18:26 <Zakim> -gkellogg
16:18:27 <PatH> I like the metaphor of a "source" or "emitter" of RDF rather than a container. For example, a human being can emit RDF from time to time. No problem with that.
16:18:27 <Zakim> -LeeF
16:18:31 <AlexHall> AlexHall has left #rdf-wg
16:18:46 <PatH> Oh, sorry, is everyone leaving? 
16:18:53 <PatH> Bye guys.
16:18:57 <Guus> not yet, Pat
16:19:00 <PatH> OK
16:19:13 <davidwood> We are staying after to discuss graphs...
16:19:49 <manu1> Sandro: Richard, I think maybe that an interesting point is what we should do about folks who want to use URI of a person as the graph label in SPARQL. We agree that people do that, and the question is whether that is a reasonable thing to do or we say that is forbidden.
16:20:09 <manu1> Sandro: I don't think we can forbid this... I think I'm more towards saying it's not okay... if you do that, you should keep that to yourself.
16:21:03 <manu1> Richard: I agree that the most important thing is that it works well for the Webby case - where yo uhave a URI, you dereference, you have triples and that's the graph that is associated with the URI.
16:21:13 <MacTed> s/even if the gSnap is not persistent/even if the gSnap is transient and not properly named\/denoted\/endowed-with-URI/
16:21:30 <manu1> Richard: I'm perfectly happy with saying that you shouldn't use the gRelation pattern.
16:21:52 <Zakim> -davidwood
16:22:05 <manu1> Richard: if you find a dataset out there in the wild, then if you don't have any additional evidence to the contrary, then you should assume that's the type of relationship that's in there.
16:22:16 <pchampin> I'm still interested, but I have to go too; sorry
16:22:26 <manu1> Richard: We really don't have to forbid anything at all - we don't want to make it illegal... you can do it and nothing breaks.
16:22:32 <Zakim> -pchampin
16:22:46 <sandro> q?
16:22:47 <PatH> FWIW, semantics never makes anything illegal :-)
16:22:51 <sandro> ack pchampin 
16:22:53 <sandro> ack sandro 
16:22:53 <Zakim> sandro, you wanted to talk about the person-as-graph-name use case
16:22:53 <manu1> Richard: The main question is the terminology that we use - how well does it work with the corner cases that we're using?
16:22:54 <Guus> I need to leave, but wonder where we give the advice how to give an identifier to a person
16:23:03 <manu1> Richard: Does it help or does it hurt - the terminology?
16:23:16 <manu1> Richard: The most important thing is that it works well for the Web case... we shouldn't say "MUST NOT".
16:23:28 <manu1> Sandro: Are you okay with saying SHOULD NOT?
16:23:35 <sandro> ("in public")
16:23:40 <Zakim> -Guus
16:23:57 <manu1> Richard: if you publish a dataset on the Web that has dereferenceable graph names as URIs, then you should do the Webby thing.
16:24:00 <sandro> cygri: If you publish a dataset on the web that has deref URIs as graph names then you should do the webby thing
16:24:13 <sandro> q+
16:24:32 <sandro> q+ to say it's not just deref URIs.
16:24:43 <MacTed> "signing graphs" means "signing gSnaps" -- it *has* to.
16:24:49 <MacTed> not gBoxes.
16:24:51 <PatH> Issue is not what publishers do, but what others do downstream with those RDF sources. 
16:25:06 <sandro> yes MacTed  (or g-text)
16:25:07 <ericP> manu1: we use named graphs for signatures in RDFa and JSON-LD. It's problematic when the language (RDFa) doesn't support named graphs, but still has to express a signature on a named graph. 
16:25:31 <ericP> ... we haven't said that it e.g. MUST include a hash, timestamp, etc.
16:25:55 <PatH> A publishes some RDF with a Webby IRI this:one, then B creates a dataset with that RDF associated with a uri that:one which denotes a human being. NOt A's fault. 
16:26:34 <PatH> And C says this:one owl:sameAs that:one
16:26:36 <AndyS> +1 toPatH
16:26:43 <sandro> q?
16:27:37 <ericP> ... we use a subject identifier as a graph identifier in signing, we don't see a way around this while staying flexible
16:28:23 <ericP> ... because RDFa will not have graph support for a long time, this group should not limit how RDFa users can use graphs
16:28:27 <PatH> MacTed, couldnt we have a notion of a 'locked' (fixed) g-box? And then sign that? Then there only has to be one kind of thing (g-boxes) but some of them have a special status.
16:29:25 <ericP> ... <asset1> { <asset1> :price $22;  }. <asset1> signatureValue "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk=". <-- The second statement applies to the graph, and is not data in the graph.
16:29:35 <MacTed> PatH - the 'locked' g-box *is* a g-snap
16:29:54 <MacTed> so a g-snap *might* be a subclass of g-box...
16:30:11 <PatH> No, its not. Sematnically its a lot easier if we keep one category, even if they have several subclasses.
16:30:24 <manu1>     "@type": "GraphSignature2011",
16:30:26 <manu1>     "creator": "http://manu.sporny.org/webid#key-5",
16:30:28 <manu1>     "signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
16:30:56 <manu1> <asset1> sec:signature [ ... ];
16:31:15 <PatH> g-snap is what you get out of the g-box, in all cases. When the box is 'locked', its the same snap every time. Guaranteed. 
16:31:30 <ericP> what if you're selling a signature?
16:32:06 <MacTed> PatH - gBoxMutable, gBoxImmutable ?
16:32:27 <PatH> The old named-graphs paper had a lot of ideas about secure signing in it, might be worth checking it out. 
16:32:44 <PatH> Bizer & Carroll did it.
16:32:54 <PatH> MacTed, yes exactly.
16:35:18 <MacTed> with gBoxMutable, gSnap-time1 may differ from gSnap-time2
16:35:18 <MacTed> with gBoxImmutable, gSnap-time1 will always be (equal? equivalent? identical modulo ordering?) to gSnap-time2
16:35:32 <AndyS> zakim, who is on the phone?
16:35:32 <Zakim> On the phone I see Sandro, manu1, cygri, AZ, AndyS, MacTed, EricP
16:36:43 <Zakim> -EricP
16:37:08 <PatH> I have to leave very soon.
16:37:39 <sandro> q?
16:37:45 <AndyS> sounds like ETL in disguise
16:39:36 <manu1> Richard: Maybe we don't need to take a position on whether or something is a gBox - we could just say resources could have state.
16:40:03 <manu1> Richard: What kind of thing could have state - could have content - our model of the Web/World - anything can have an associated graph state.
16:40:23 <manu1> Sandro: I pretty much agree with that - how do we explain that to the rest of the world - maybe no terminology would be best.
16:40:29 <MacTed> "resources can have state" -- essentially rephrases "context lenses" through which to view a resource...
16:40:44 <Zakim> -manu1
16:40:46 <Zakim> -cygri
16:40:48 <Zakim> -MacTed
16:40:48 <Zakim> -Sandro
16:40:49 <Zakim> -AndyS
16:40:51 <Zakim> -AZ
16:40:51 <Zakim> SW_RDFWG()11:00AM has ended
16:40:51 <Zakim> Attendees were Guus, Ivan, AndyS, davidwood, gkellogg, Sandro, pfps, Tom_Baker, manu1, cygri, AZ, +1.443.212.aaaa, AlexHall, gavinc, zwu2, MacTed, pchampin, swh, EricP, LeeF
16:41:04 <AndyS> AndyS has left #rdf-wg
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000508