Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Added text and audio logs for 2012-05-29 telecon.

  • Loading branch information...
commit 74cb0ec7956581a48223999af4a4bcf1b4df2693 1 parent a07699e
Manu Sporny authored May 29, 2012
BIN  2012-05-29/audio.ogg
Binary file not shown
218  2012-05-29/index.html
... ...
@@ -0,0 +1,218 @@
  1
+<!DOCTYPE html> 
  2
+ 
  3
+<html> 
  4
+<head> 
  5
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 
  6
+  <title>Linked Data in JSON Telecon</title> 
  7
+  
  8
+  <style type="text/css"> 
  9
+body {
  10
+   max-width: 50em;
  11
+   margin: auto;
  12
+   font-family: "HelveticaNeue-Light", "Helvetica Neue Light", "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;
  13
+   font-weight: 300;
  14
+}
  15
+
  16
+label {
  17
+   float: left;
  18
+   text-align: right;
  19
+   margin-right: 15px;
  20
+   width: 100px;
  21
+}
  22
+
  23
+a {
  24
+   color: #4183c4;
  25
+}
  26
+
  27
+ol {
  28
+   padding-left: 1.2em;
  29
+   margin: 0em;
  30
+}
  31
+ 
  32
+.name {
  33
+   font-weight: bold;
  34
+}
  35
+ 
  36
+.information {
  37
+   font-style: italic;
  38
+}
  39
+ 
  40
+.comment-continuation {
  41
+   margin-left: 2em;
  42
+}
  43
+ 
  44
+.proposal {
  45
+   background: #eee;
  46
+   border: 0.2em solid #c4c8cc;
  47
+   margin: 1em;
  48
+   border-radius: 1em 1em 1em 1em;
  49
+   padding: 1em 1em 1em 1em;
  50
+}
  51
+ 
  52
+.resolution {
  53
+   background: #beb;
  54
+   border: 0.2em solid #c4c8cc;
  55
+   margin: 1em;
  56
+   border-radius: 1em 1em 1em 1em;
  57
+   padding: 1em 1em 1em 1em;
  58
+}
  59
+ 
  60
+.action {
  61
+   background: #bbe;
  62
+   border: 0.2em solid #c4c8cc;
  63
+   margin: 1em;
  64
+   border-radius: 1em 1em 1em 1em;
  65
+   padding: 1em 1em 1em 1em;
  66
+}
  67
+  </style> 
  68
+</head> 
  69
+ 
  70
+<body> 
  71
+<h1>JSON-LD Community Group Telecon</h1>
  72
+<h2>Minutes for 2012-05-29</h2>
  73
+<div class="summary">
  74
+<dl>
  75
+<dt>Agenda</dt><dd><a href="http://lists.w3.org/Archives/Public/public-linked-json/2012May/0072.html">http://lists.w3.org/Archives/Public/public-linked-json/2012May/0072.html</a></dd>
  76
+<dt>Topics</dt><dd><ol><li><a href="#topic-1">RDF WG Spec Concerns</a><li><a href="#topic-2">Concerns about Publishing JSON-LD API</a><li><a href="#topic-3">JSON-LD CG to RDF WG document transition</a></ol></dd><dt>Chair</dt><dd>Manu Sporny</dd>
  77
+<dt>Scribe</dt><dd>Markus Lanthaler</dd>
  78
+<dt>Present</dt><dd>Markus Lanthaler, Manu Sporny, Richard Cyganiak, David Wood, Ivan Herman, Gregg Kellogg, François Daoust, David I. Lehn</dd>
  79
+<dt>Audio Log</dt><dd><div><a href="audio.ogg">audio.ogg</a></div>
  80
+<div><audio controls="controls" preload="none">
  81
+<source src="audio.ogg" type="audio/ogg" />Warning: Your browser does not support the HTML5 audio element, please upgrade.</audio></div></dd></dl></div>
  82
+<div class="information">Markus Lanthaler is scribing.</div>
  83
+<h1 id="topic-1" class="topic">Topic: RDF WG Spec Concerns</h1>
  84
+<div class="comment"><span class="name">Manu Sporny</span>: <a href="https://github.com/json-ld/json-ld.org/issues/127">https://github.com/json-ld/json-ld.org/issues/127</a></div>
  85
+<div class="comment"><span class="name">Manu Sporny</span>: <a href="https://github.com/json-ld/json-ld.org/issues/131">https://github.com/json-ld/json-ld.org/issues/131</a></div>
  86
+<div class="comment"><span class="name">Manu Sporny</span>:  Richard, would you mind giving a quick overview of the issues you raised?</div>
  87
+<div class="comment-continuation">... also Pat Hayes raised some issues, which are also tracked in ISSUE-131</div>
  88
+<div class="comment"><span class="name">Richard Cyganiak</span>:  the issues that I raised are mostly about the API spec, WebIDL stuff</div>
  89
+<div class="comment-continuation">... the terminology should be changed to match the RDF Concepts</div>
  90
+<div class="comment-continuation">... the normative definition of the data model is in the RDF Concepts spec.</div>
  91
+<div class="comment-continuation">... issue 131 is basically about aligning the terminology with what we have in RDF Concepts</div>
  92
+<div class="comment-continuation">... some problems come from the fact that JSON-LD is slightly different than what RDF COncepts talks about and defines some things as a programmatic interface via WebIDL, so it might not always work out nicely</div>
  93
+<div class="comment-continuation">... nevertheless it's still worth trying to align it.</div>
  94
+<div class="comment-continuation">... I agree with Pat that some things are not that clear in text - graphs etc. - Pat gave some good input there.</div>
  95
+<div class="comment"><span class="name">Manu Sporny</span>:  I think both of you made some good points</div>
  96
+<div class="comment-continuation">... we are going to be trying to address them in the next few weeks</div>
  97
+<div class="comment-continuation">... the confusion is probably for a number of reasons: 1) The JSON-LD API spec wasn't ready for review, 2) We have slightly different terminology because of the Linked Data vs. RDF stuff and 3) Hold-overs from the RDF API that is language that is over 18 months old.</div>
  98
+<div class="comment-continuation">... there are some things like predicate vs. property where we might need some more discussion.. but there shouldn't be any show-stoppers here</div>
  99
+<div class="comment-continuation">... some terms were pulled over from the RDF API spec which is clearly outdated</div>
  100
+<div class="comment"><span class="name">David Wood</span>:  the RDF WG is very happy with JSON-LD so far.</div>
  101
+<div class="comment-continuation">... even Turtle - which is everyone's darling - has these problems... we have been tweaking it now for a year and are still not done yet</div>
  102
+<div class="comment-continuation">... I think we are all very happy working with JSON-LD</div>
  103
+<div class="comment"><span class="name">Manu Sporny</span>:  I don't see any show stoppers at this point either, good.</div>
  104
+<div class="comment-continuation">... I hope no one in the RDF WG sees any show stoppers.</div>
  105
+<h1 id="topic-2" class="topic">Topic: Concerns about Publishing JSON-LD API</h1>
  106
+<div class="comment"><span class="name">Manu Sporny</span>:  The one thing I can see is that the RDF WG might not be interested in publishing the API due to potential charter issues.</div>
  107
+<div class="comment"><span class="name">Ivan Herman</span>:  outsiders that need to approve what the WG does might disagree because the API is not on the charter.</div>
  108
+<div class="comment-continuation">... depends also what will be done with the RDF conversion stuff</div>
  109
+<div class="comment-continuation">... those algorithms have to end up in the RDF WG at some point, the other JSON-LD API methods like compact/expand/etc. don't necessarily have to end up in RDF WG.</div>
  110
+<div class="comment-continuation">... I'm still a bit uncertain about the other algorithms</div>
  111
+<div class="comment-continuation">... there is an alternative - extract RDF algorithms in a separate document or put them into the syntax doc.</div>
  112
+<div class="comment"><span class="name">Gregg Kellogg</span>:  I did most of the work on the RDF conversion algorithms</div>
  113
+<div class="comment"><span class="name">Gregg Kellogg</span>:  the RDF algorithms depend on the expansion algorithm, so we'd have to move that over as well.</div>
  114
+<div class="comment-continuation">... framing is more experimental...</div>
  115
+<div class="comment-continuation">... compaction is used to make JSON-LD more human-readable</div>
  116
+<div class="comment-continuation">... so we will at least need expansion for the RDF algorithms.</div>
  117
+<div class="comment-continuation">... I don't think the RDF algorithms are tightly bound to the API (WebIDL), we could separate them.</div>
  118
+<div class="comment-continuation">... it would be fairly straightforward to separate the algorithms from the WebIDL stuff.</div>
  119
+<div class="comment"><span class="name">Manu Sporny</span>:  I'm somewhat concerned on changing the spec based on what the RDF WG charter says instead of doing what would make most sense</div>
  120
+<div class="comment"><span class="name">David Wood</span>:  as long as go over the patent-policy hurdle it's easier... otherwise we have a major problem.</div>
  121
+<div class="comment"><span class="name">Richard Cyganiak</span>:  it would be a bit premature to talk about graphs since the RDF WG is still discussing that... most likely not quads but more what SPARQL does.</div>
  122
+<div class="comment-continuation">... JSON-LD isn't one monolithic thing.. there is syntax, algorithms, etc. and different parts have different levels of maturity</div>
  123
+<div class="comment"><span class="name">Manu Sporny</span>: +1 to what cygri just said.</div>
  124
+<div class="comment-continuation">... so it might reasonable to go with through the W3C process with the mature ones and split out the rest (for the time being)</div>
  125
+<div class="comment"><span class="name">Ivan Herman</span>:  some of the algorithms in the API spec need the term experimental</div>
  126
+<div class="comment-continuation">... that worries me a bit</div>
  127
+<div class="comment-continuation">... if we take them through the whole process it will keep back JSON-LD from being standardized in time (the RDF charter is fixed)</div>
  128
+<div class="comment-continuation">... which would mean that we can't finalize JSON-LD Syntax either</div>
  129
+<div class="comment-continuation">... I'm in favour of extracting the RDF algorithms, put it into syntax spec and go on</div>
  130
+<div class="comment"><span class="name">Manu Sporny</span>:  that's one path forward</div>
  131
+<div class="comment-continuation">... and we don't want the API to become the blocker</div>
  132
+<div class="comment-continuation">... maybe two docs (syntax + RDF algorithms) and take them to REC...</div>
  133
+<div class="comment-continuation">... and publish the rest of the API at a later point in time</div>
  134
+<div class="comment"><span class="name">Ivan Herman</span>:  for me the algorithmic description of how to transform JSON-LD to RDF and vice versa would be enough.. doesn't have to be specified in terms of an API</div>
  135
+<div class="comment"><span class="name">Gregg Kellogg</span>:  most of the body of the API spec is algorithmic and the WebIDL part is quite small</div>
  136
+<div class="comment-continuation">... so we could describe the algorithms not using API terms pretty easily since it's already done like that.</div>
  137
+<div class="comment"><span class="name">Manu Sporny</span>:  if we reorganize the specs there will be quite some discussion on how to do it, I'm afraid of burning time doing this</div>
  138
+<div class="comment-continuation">... we would be adding a bit of overhead here...</div>
  139
+<div class="comment-continuation">... part of me is concerned that we are doing all of this work just because we're standardizing in RDF WG vs. a JSON-LD WG</div>
  140
+<div class="comment"><span class="name">Ivan Herman</span>:  that's not quite correct</div>
  141
+<div class="comment-continuation">... if the RDF WG is going to publish a standard it has to be fully specified and complete</div>
  142
+<div class="comment"><span class="name">David Wood</span>: +1 to Ivan; The spec needs to be complete, including the RDF conversion.</div>
  143
+<div class="comment-continuation">... the RDF conversion is integral and has to be on the same level of maturity of the JSON-LD spec itself</div>
  144
+<div class="comment-continuation">... and that's why we are going down this discussion</div>
  145
+<div class="comment"><span class="name">Manu Sporny</span>:  RDF conversion is a requirement of the RDF WG but it wouldn't be a requirement for a JSON-LD WG</div>
  146
+<div class="comment-continuation">... if we would go through another WG we wouldn't be having this discussion... just outlining this point - we'd still publish a to/from RDF conversion algorithm.</div>
  147
+<div class="comment"><span class="name">Ivan Herman</span>:  the problem is that we are pushing one doc through the process and not the other</div>
  148
+<div class="comment"><span class="name">Manu Sporny</span>:  no, both would be there.. to/from RDF in a separate doc and the JSON-LD Syntax - that's the best approach we have right now.</div>
  149
+<div class="comment"><span class="name">Ivan Herman</span>:  I would be fine with that</div>
  150
+<div class="comment"><span class="name">David Wood</span>:  I'm wondering how much "Linked Data" JSON-LD can be if it can't be transformed to RDF</div>
  151
+<div class="comment"><span class="name">Manu Sporny</span>:  just as an example.. internally at Digital Bazaar we use JSON-LD completely without RDF (no triples, no triple store, no SPARQL, etc.)</div>
  152
+<div class="comment-continuation">... I'm not saying the conversion to RDF isn't useful... it's just not necessary in our case.</div>
  153
+<div class="comment"><span class="name">François Daoust</span>: I agree with Manu. JSON-LD is pretty useful without the RDF bits.</div>
  154
+<div class="comment"><span class="name">Manu Sporny</span>:  I'm just saying it stands on it's own</div>
  155
+<div class="comment"><span class="name">David Wood</span>:  it's not the use of a triple store that defines RDF. RDF is a data model.</div>
  156
+<div class="comment-continuation">... and that data model has its use as well without triple stores, etc.</div>
  157
+<div class="comment"><span class="name">Gregg Kellogg</span>:  a lot of those issues go back to last summer when we discussed what Linked Data is</div>
  158
+<div class="comment-continuation">... a lot of people jumped in and said Linked Data != RDF</div>
  159
+<div class="comment-continuation">... that's were that "bnode is not linked data" statement comes from</div>
  160
+<div class="comment-continuation">... we just have to make sure to not get into the way of developers that had bad experiences with RDF before... it's a hard line to walk.</div>
  161
+<div class="comment"><span class="name">Richard Cyganiak</span>:  your linked data model is quite in line with what RDF's data model is</div>
  162
+<div class="comment-continuation">... another option: could we put the data model that you define in the API spec into the RDF Concepts</div>
  163
+<div class="comment"><span class="name">Gregg Kellogg</span>: +1 to cygri</div>
  164
+<div class="comment"><span class="name">Manu Sporny</span>:  JSON-LD is basically RDF but we try to paper over RDF with language that is more accessible to non-computer-science-types... to make it compelling for web developers.</div>
  165
+<div class="comment-continuation">... so I don't know if using the RDF Concepts terminology scares average developers away.</div>
  166
+<div class="comment"><span class="name">Markus Lanthaler</span>:  Simple question - if you're looking at the API spec, there are a number of algorithms in there - the only experimental one in there right now is framing... why not just pull that out? [scribe assist by Manu Sporny]</div>
  167
+<div class="comment"><span class="name">Markus Lanthaler</span>:  expansion, compaction, to/from RDF are fairly stable.... [scribe assist by Manu Sporny]</div>
  168
+<div class="comment"><span class="name">Ivan Herman</span>:  So, perhaps we could take framing out and just publish JSON-LD API? [scribe assist by Manu Sporny]</div>
  169
+<div class="comment"><span class="name">Ivan Herman</span>:  then we might just extract framing and publish the rest if it's stable</div>
  170
+<div class="comment"><span class="name">Markus Lanthaler</span>:  The other question is how long is the process going to take? If we start the process now, we don't have to publish the standard tomorrow or in two weeks? [scribe assist by Manu Sporny]</div>
  171
+<div class="comment"><span class="name">Ivan Herman</span>:  Until Last Call - we can have features in there that won't be in the standard... that's fine in a First Public Working Draft and Working Drafts. [scribe assist by Manu Sporny]</div>
  172
+<div class="comment"><span class="name">Markus Lanthaler</span>:  I think we're discussing a lot of things that are not critical - we can extract this stuff into another document at a later time. [scribe assist by Manu Sporny]</div>
  173
+<div class="comment"><span class="name">Manu Sporny</span>:  Maybe we publish JSON-LD Syntax and JSON-LD API (modulo framing)? [scribe assist by Manu Sporny]</div>
  174
+<div class="comment"><span class="name">Manu Sporny</span>:  would it be OK for the RDF WG to proceed with the syntax and API spec and maybe take out framing (now or later)</div>
  175
+<div class="comment"><span class="name">Ivan Herman</span>:  the only concern I have is that APIs are not in the RDF WG charter</div>
  176
+<div class="comment"><span class="name">David Wood</span>:  I don't think it's our biggest issue... we may be making this into a bigger issue than it is.</div>
  177
+<div class="comment"><span class="name">Manu Sporny</span>:  so would you see that as a way forward? We publish JSON-LD Syntax and JSON-LD API (without framing)? I can send an e-mail to this effect if we're all okay with this approach.</div>
  178
+<div class="comment"><span class="name">David Wood</span>:  yes, I think that's fine</div>
  179
+<div class="comment-continuation">... but prepare to be flexible and together we will find a way forward...</div>
  180
+<div class="comment"><span class="name">Richard Cyganiak</span>:  the few of us that are here today can't speak for the majority of the RDF WG</div>
  181
+<div class="comment-continuation">... you never know what may come up during the discussion</div>
  182
+<div class="comment-continuation">... people often feel reluctant to agree on something that they don't understand</div>
  183
+<div class="comment-continuation">... so you will probably need to do a lot of explaining.</div>
  184
+<div class="comment"><span class="name">David Wood</span>: +1 to Richard - expect to explain (and be flexible)</div>
  185
+<div class="comment-continuation">... what this group is proposing is bigger than just a simple JSON serialization (not that that is a bad thing)</div>
  186
+<div class="comment-continuation">... you have to be prepared for push-back on that</div>
  187
+<div class="comment-continuation">... it takes time but is not a fundamental obstacle</div>
  188
+<div class="comment"><span class="name">Manu Sporny</span>:  I hope we get enough time to explain the stuff, I'd hate to be given only one telecon to summarize, explain and defend 18+ months of work.</div>
  189
+<div class="comment"><span class="name">David Wood</span>:  well you have specs that can be read, that's a positive. Folks are going to have to RTFM before raising real technical issues.</div>
  190
+<h1 id="topic-3" class="topic">Topic: JSON-LD CG to RDF WG document transition</h1>
  191
+<div class="comment"><span class="name">Manu Sporny</span>: <a href="http://www.w3.org/community/reports/reqs/">http://www.w3.org/community/reports/reqs/</a></div>
  192
+<div class="comment"><span class="name">Manu Sporny</span>:  there are very specific steps to transition from a CG to the WG</div>
  193
+<div class="comment-continuation">... the two major things we need to do</div>
  194
+<div class="comment-continuation">... 1) All JSON-LD CG members that contributed text to the spec will have to fill out the patent coverage form so that copyright and patent coverage is clear.</div>
  195
+<div class="comment-continuation">... 2) We need to change the copyright from Creative Commons Attribution 1.0 to the permissive W3C license (which still allows us to fork the spec if things go terribly wrong)</div>
  196
+<div class="comment-continuation">... once we transfer the document to the RDF WG, it can not be worked on by non-RDF WG members anymore.</div>
  197
+<div class="comment"><span class="name">Manu Sporny</span>:  so we need to make sure that everyone in the CG that is contributing work is an invited expert or similar to be able to continue to work on this</div>
  198
+<div class="comment"><span class="name">David Wood</span>:  you should apply via the invited expert form if you have not done so already</div>
  199
+<div class="comment"><span class="name">Manu Sporny</span>:  the only other remaing thing: how do we track issues?</div>
  200
+<div class="comment-continuation">... is it ok to continue on GitHub?</div>
  201
+<div class="comment"><span class="name">Ivan Herman</span>:  there's no process issue with this</div>
  202
+<div class="comment-continuation">... only thing is that you can proof that all issues have been taken into account</div>
  203
+<div class="comment-continuation">... as soon as we have a FPWD we move over the issue tracker to make collaboration easier</div>
  204
+<div class="comment"><span class="name">Manu Sporny</span>:  should we continue to have separate telecons?</div>
  205
+<div class="comment"><span class="name">David I. Lehn</span>: May be more efficient to do so.</div>
  206
+<div class="comment"><span class="name">Ivan Herman</span>:  yes, I thought about that.. we might need to do this for the time being</div>
  207
+<div class="comment-continuation">... but the RDF WG would need to make the final resolutions.</div>
  208
+<div class="comment-continuation">... on a different note: the canonilization should really be separate from JSON-LD...</div>
  209
+<div class="comment"><span class="name">Manu Sporny</span>:  yes, we separated it - and we think we have a generalized RDF graph normalization algorithm. The serialization format is in quads, which is why we have Quads in the JSON-LD API.</div>
  210
+<div class="comment-continuation">... so, yes I think we have a generic normalization algorithm now</div>
  211
+<div class="comment"><span class="name">David Wood</span>: That would make a nice WG Note, but we aren't chartered to standardize it.</div>
  212
+<div class="comment"><span class="name">David Wood</span>: Yes, Ivan and I agree</div>
  213
+<div class="comment"><span class="name">Ivan Herman</span>:  this is not something that the RDF WG would publish as a spec but at least as a working group note and specify it in two years or so</div>
  214
+<div class="comment"><span class="name">David Wood</span>: The RDF WG will consider n-quads, but not yet</div>
  215
+<div class="comment"><span class="name">Gregg Kellogg</span>:  does the WG considers standardizing N-Quads?</div>
  216
+<div class="comment"><span class="name">Ivan Herman</span>:  there's no consensus on this</div>
  217
+</body>
  218
+</html>
238  2012-05-29/irc.log
... ...
@@ -0,0 +1,238 @@
  1
+[10:03]	<manu1>	Agenda: http://lists.w3.org/Archives/Public/public-linked-json/2012May/0072.html
  2
+[10:03]	<voip-ld>	<unknown> (IAX2/diamondcard-13302) has joined the conference.
  3
+[10:04]	<manu1>	scribe: mlnt
  4
+[10:04]	<manu1>	voip: 13302 is ivan_herman
  5
+[10:04]	<voip-ld>	ivan_herman is now associated with IAX2/diamondcard-13302.
  6
+[10:05]	<manu1>	Topic: RDF WG Spec Concerns
  7
+[10:05]	<manu1>	https://github.com/json-ld/json-ld.org/issues/127
  8
+[10:05]	<manu1>	https://github.com/json-ld/json-ld.org/issues/131
  9
+[10:05]	<mlnt>	manu: Richard, would you mind giving a quick overview of the issues you raised?
  10
+[10:06]	<mlnt>	... also Pat Hayes raised some issues, which are also tracked in ISSUE-131
  11
+[10:07]	<mlnt>	richard: the issues that I raised are mostly about the API spec, WebIDL stuff
  12
+[10:08]	<mlnt>	... the terminology should be changed to match the RDF Concepts
  13
+[10:08]	<manu1>	q+ to discuss the origins of these terms.
  14
+[10:08]	<voip-ld>	Added manu1 to the speaker queue: manu1
  15
+[10:08]	<mlnt>	... the normative definition of the data model is in the RDF Concepts spec.
  16
+[10:09]	<mlnt>	... issue 131 is basically about aligning the terminology with what we have in RDF Concepts
  17
+[10:09]	<mlnt>	... some problems come from the fact that JSON-LD is slightly different than what RDF COncepts talks about and defines some things as a programmatic interface via WebIDL, so it might not always work out nicely
  18
+[10:09]	<mlnt>	... nevertheless it's still worth trying to align it.
  19
+[10:10]	<manu1>	ack manu1
  20
+[10:10]	<voip-ld>	manu1 has the floor (to discuss the origins of these terms.). The speaker queue is empty.
  21
+[10:10]	<mlnt>	... I agree with Pat that some things are not that clear in text - graphs etc. - Pat gave some good input there.
  22
+[10:10]	<mlnt>	manu: I think both of you made some good points
  23
+[10:11]	<mlnt>	... we are going to be trying to address them in the next few weeks
  24
+[10:11]	<mlnt>	... the confusion is probably for a number of reasons: 1) The JSON-LD API spec wasn't ready for review, 2) We have slightly different terminology because of the Linked Data vs. RDF stuff and 3) Hold-overs from the RDF API that is language that is over 18 months old.
  25
+[10:12]	<mlnt>	... there are some things like predicate vs. property where we might need some more discussion.. but there shouldn't be any show-stoppers here
  26
+[10:12]	<mlnt>	... some terms were pulled over from the RDF API spec which is clearly outdated
  27
+[10:12]	<mlnt>	prototypo: the RDF WG is very happy with JSON-LD so far.
  28
+[10:13]	<mlnt>	... even Turtle - which is everyone's darling - has these problems... we have been tweaking it now for a year and are still not done yet
  29
+[10:14]	<mlnt>	... I think we are all very happy working with JSON-LD
  30
+[10:14]	<mlnt>	manu: I don't see any show stoppers at this point either, good.
  31
+[10:14]	<mlnt>	... I hope no one in the RDF WG sees any show stoppers.
  32
+[10:15]	<manu>	Topic: Concerns about Publishing JSON-LD API
  33
+[10:15]	<mlnt>	manu: The one thing I can see is that the RDF WG might not be interested in publishing the API due to potential charter issues.
  34
+[10:15]	* manu1	markus - this is ivan speaking.
  35
+[10:16]	<mlnt>	ivan: outsiders that need to approve what the WG does might disagree because the API is not on the charter.
  36
+[10:16]	<mlnt>	... depends also what will be done with the RDF conversion stuff
  37
+[10:17]	<mlnt>	... those algorithms have to end up in the RDF WG at some point, the other JSON-LD API methods like compact/expand/etc. don't necessarily have to end up in RDF WG.
  38
+[10:17]	<mlnt>	... I'm still a bit uncertain about the other algorithms
  39
+[10:17]	<gkellogg>	q+
  40
+[10:17]	<voip-ld>	Added gkellogg to the speaker queue: gkellogg
  41
+[10:17]	<voip-ld>	Richard Cyganiak (SIP/ekiga.net-0000000a) has left the conference.
  42
+[10:17]	<mlnt>	... there is an alternative - extract RDF algorithms in a separate document or put them into the syntax doc.
  43
+[10:17]	<manu1>	ack gkellogg
  44
+[10:17]	<voip-ld>	gkellogg has the floor. The speaker queue is empty.
  45
+[10:18]	<voip-ld>	Richard Cyganiak (SIP/ekiga.net-0000000c) has joined the conference.
  46
+[10:18]	<mlnt>	gregg: I did most of the work on the RDF conversion algorithms
  47
+[10:18]	<mlnt>	gregg: the RDF algorithms depend on the expansion algorithm, so we'd have to move that over as well.
  48
+[10:18]	<mlnt>	... framing is more experimental...
  49
+[10:18]	<manu1>	q+ to express concern about splitting the docs up based on charters instead of functionality.
  50
+[10:18]	<voip-ld>	Added manu1 to the speaker queue: manu1
  51
+[10:19]	<mlnt>	... compaction is used to make JSON-LD more human-readable
  52
+[10:19]	<mlnt>	... so we will at least need expansion for the RDF algorithms.
  53
+[10:19]	<mlnt>	... I don't think the RDF algorithms are tightly bound to the API (WebIDL), we could separate them.
  54
+[10:19]	<cygri>	q+
  55
+[10:19]	<voip-ld>	Added cygri to the speaker queue: manu1, cygri
  56
+[10:20]	<manu1>	ack
  57
+[10:20]	<mlnt>	... it would be fairly straightforward to separate the algorithms from the WebIDL stuff.
  58
+[10:20]	<voip-ld>	manu1 has the floor (to express concern about splitting the docs up based on charters instead of functionality.). The next speaker is cygri.
  59
+[10:20]	<mlnt>	manu: I'm somewhat concerned on changing the spec based on what the RDF WG charter says instead of doing what would make most sense
  60
+[10:21]	<ivan_herman>	q+
  61
+[10:21]	<voip-ld>	Added ivan_herman to the speaker queue: manu1, ivan_herman
  62
+[10:21]	* manu1	sorry cygri - will get to you.
  63
+[10:21]	<manu1>	ack manu1
  64
+[10:21]	<voip-ld>	manu1 has the floor. The next speaker is ivan_herman.
  65
+[10:21]	<mlnt>	prototypo: as long as go over the patent-policy hurdle it's easier... otherwise we have a major problem.
  66
+[10:22]	<manu1>	q+ to mention why we have quads.
  67
+[10:22]	<voip-ld>	Added manu1 to the speaker queue: manu1, manu1
  68
+[10:22]	<mlnt>	richard: it would be a bit premature to talk about graphs since the RDF WG is still discussing that... most likely not quads but more what SPARQL does.
  69
+[10:23]	<mlnt>	... JSON-LD isn't one monolithic thing.. there is syntax, algorithms, etc. and different parts have different levels of maturity
  70
+[10:23]	<manu1>	+1 to what cygri just said.
  71
+[10:24]	<mlnt>	... so it might reasonable to go with through the W3C process with the mature ones and split out the rest (for the time being)
  72
+[10:24]	<manu1>	ack
  73
+[10:24]	<voip-ld>	manu1 has the floor. The next speaker is manu1.
  74
+[10:24]	<mlnt>	ivan: some of the algorithms in the API spec need the term experimental
  75
+[10:24]	<mlnt>	... that worries me a bit
  76
+[10:25]	<mlnt>	... if we take them through the whole process it will keep back JSON-LD from being standardized in time (the RDF charter is fixed)
  77
+[10:25]	<mlnt>	... which would mean that we can't finalize JSON-LD Syntax either
  78
+[10:26]	<manu1>	ack manu1
  79
+[10:26]	<voip-ld>	manu1 has the floor (to mention why we have quads.). The speaker queue is empty.
  80
+[10:26]	<mlnt>	... I'm in favour of extracting the RDF algorithms, put it into syntax spec and go on
  81
+[10:26]	<mlnt>	manu: that's one path forward
  82
+[10:26]	<mlnt>	... and we don't want the API to become the blocker
  83
+[10:27]	<mlnt>	... maybe two docs (syntax + RDF algorithms) and take them to REC...
  84
+[10:27]	<mlnt>	... and publish the rest of the API at a later point in time
  85
+[10:27]	<gkellogg>	q+
  86
+[10:27]	<voip-ld>	Added gkellogg to the speaker queue: gkellogg
  87
+[10:29]	<mlnt>	ivan: for me the algorithmic description of how to transform JSON-LD to RDF and vice versa would be enough.. doesn't have to be specified in terms of an API
  88
+[10:29]	<manu1>	ack gkellogg
  89
+[10:29]	<voip-ld>	gkellogg has the floor. The speaker queue is empty.
  90
+[10:30]	<cygri>	q+
  91
+[10:30]	<voip-ld>	Added cygri to the speaker queue: cygri
  92
+[10:30]	<mlnt>	gregg: most of the body of the API spec is algorithmic and the WebIDL part is quite small
  93
+[10:31]	<mlnt>	... so we could describe the algorithms not using API terms pretty easily since it's already done like that.
  94
+[10:31]	<cygri>	q-
  95
+[10:31]	<voip-ld>	Removed cygri from the speaker queue: (empty)
  96
+[10:32]	<mlnt>	manu: if we reorganize the specs there will be quite some discussion on how to do it, I'm afraid of burning time doing this
  97
+[10:32]	<mlnt>	... we would be adding a bit of overhead here...
  98
+[10:32]	<mlnt>	... part of me is concerned that we are doing all of this work just because we're standardizing in RDF WG vs. a JSON-LD WG
  99
+[10:33]	<mlnt>	ivan: that's not quite correct
  100
+[10:33]	<mlnt>	... if the RDF WG is going to publish a standard it has to be fully specified and complete
  101
+[10:33]	<prototypo>	+1 to Ivan; The spec needs to be complete, including the RDF conversion.
  102
+[10:33]	<voip-ld>	Richard Cyganiak (SIP/ekiga.net-0000000c) has left the conference.
  103
+[10:34]	<mlnt>	... the RDF conversion is integral and has to be on the same level of maturity of the JSON-LD spec itself
  104
+[10:34]	<voip-ld>	Richard Cyganiak (SIP/ekiga.net-0000000d) has joined the conference.
  105
+[10:34]	<mlnt>	... and that's why we are going down this discussion
  106
+[10:34]	<mlnt>	manu: RDF conversion is a requirement of the RDF WG but it wouldn't be a requirement for a JSON-LD WG
  107
+[10:35]	<mlnt>	... if we would go through another WG we wouldn't be having this discussion... just outlining this point - we'd still publish a to/from RDF conversion algorithm.
  108
+[10:35]	<prototypo>	q+
  109
+[10:35]	<voip-ld>	Added prototypo to the speaker queue: prototypo
  110
+[10:35]	<mlnt>	ivan: the problem is that we are pushing one doc through the process and not the other
  111
+[10:35]	<mlnt>	manu: no, both would be there.. to/from RDF in a separate doc and the JSON-LD Syntax - that's the best approach we have right now.
  112
+[10:36]	<mlnt>	ivan: I would be fine with that
  113
+[10:36]	<manu1>	ack prototypo
  114
+[10:36]	<voip-ld>	prototypo has the floor. The speaker queue is empty.
  115
+[10:36]	<mlnt>	prototypo: I'm wondering how much "Linked Data" JSON-LD can be if it can't be transformed to RDF
  116
+[10:37]	<manu1>	q+ to state that json-ld is useful w/o RDF.
  117
+[10:37]	<voip-ld>	Added manu1 to the speaker queue: manu1
  118
+[10:37]	<mlnt>	manu: just as an example.. internally at Digital Bazaar we use JSON-LD completely without RDF (no triples, no triple store, no SPARQL, etc.)
  119
+[10:37]	<prototypo>	q+ to respond
  120
+[10:37]	<voip-ld>	Added prototypo to the speaker queue: manu1, prototypo
  121
+[10:37]	<mlnt>	... I'm not saying the conversion to RDF isn't useful... it's just not necessary in our case.
  122
+[10:37]	<manu1>	ack manu1
  123
+[10:37]	<voip-ld>	manu1 has the floor (to state that json-ld is useful w/o RDF.). The next speaker is prototypo.
  124
+[10:37]	<tidoust>	I agree with Manu. JSON-LD is pretty useful without the RDF bits.
  125
+[10:37]	<manu1>	ack prototypo
  126
+[10:37]	<voip-ld>	manu1 has the floor (to respond). The speaker queue is empty.
  127
+[10:38]	<mlnt>	manu: I'm just saying it stands on it's own
  128
+[10:38]	<mlnt>	prototypo: it's not the use of a triple store that defines RDF. RDF is a data model.
  129
+[10:38]	<--|	paulkmoore has left #json-ld ("Leaving")
  130
+[10:39]	<mlnt>	... and that data model has its use as well without triple stores, etc.
  131
+[10:39]	<gkellogg>	q+
  132
+[10:39]	<voip-ld>	Added gkellogg to the speaker queue: gkellogg
  133
+[10:39]	<cygri>	q+
  134
+[10:39]	<voip-ld>	Added cygri to the speaker queue: gkellogg, cygri
  135
+[10:39]	<manu1>	ack gkellogg
  136
+[10:39]	<voip-ld>	gkellogg has the floor. The next speaker is cygri.
  137
+[10:40]	<mlnt>	gregg: a lot of those issues go back to last summer when we discussed what Linked Data is
  138
+[10:40]	<mlnt>	... a lot of people jumped in and said Linked Data != RDF
  139
+[10:40]	<mlnt>	... that's were that "bnode is not linked data" statement comes from
  140
+[10:41]	<manu1>	ack cygri
  141
+[10:41]	<voip-ld>	gkellogg has the floor. The speaker queue is empty.
  142
+[10:41]	<manu1>	ack gkellogg
  143
+[10:41]	<mlnt>	... we just have to make sure to not get into the way of developers that had bad experiences with RDF before... it's a hard line to walk.
  144
+[10:42]	<mlnt>	richard: your linked data model is quite in line with what RDF's data model is
  145
+[10:43]	<mlnt>	... another option: could we put the data model that you define in the API spec into the RDF Concepts
  146
+[10:43]	<gkellogg>	+1 to cygri
  147
+[10:44]	<mlnt>	manu: JSON-LD is basically RDF but we try to paper over RDF with language that is more accessible to non-computer-science-types... to make it compelling for web developers.
  148
+[10:45]	<mlnt>	... so I don't know if using the RDF Concepts terminology scares average developers away.
  149
+[10:45]	<mlnt>	q+
  150
+[10:45]	<voip-ld>	Added mlnt to the speaker queue: mlnt
  151
+[10:46]	<manu1>	ack mlnt
  152
+[10:46]	<voip-ld>	mlnt has the floor. The speaker queue is empty.
  153
+[10:46]	<manu1>	mlnt: Simple question - if you're looking at the API spec, there are a number of algorithms in there - the only experimental one in there right now is framing... why not just pull that out?
  154
+[10:46]	<manu1>	mlnt: expansion, compaction, to/from RDF are fairly stable....
  155
+[10:48]	<manu1>	ivan: So, perhaps we could take framing out and just publish JSON-LD API?
  156
+[10:48]	<mlnt>	ivan: then we might just extract framing and publish the rest if it's stable
  157
+[10:49]	<manu1>	mlnt: The other question is how long is the process going to take? If we start the process now, we don't have to publish the standard tomorrow or in two weeks?
  158
+[10:49]	<manu1>	q+ to discuss the process to standardization.
  159
+[10:49]	<voip-ld>	Added manu1 to the speaker queue: manu1
  160
+[10:50]	<voip-ld>	Richard Cyganiak (SIP/ekiga.net-0000000d) has left the conference.
  161
+[10:50]	<voip-ld>	Richard Cyganiak (SIP/ekiga.net-0000000e) has joined the conference.
  162
+[10:50]	<manu1>	ivan: Until Last Call - we can have features in there that won't be in the standard... that's fine in a First Public Working Draft and Working Drafts.
  163
+[10:52]	<manu1>	mlnt: I think we're discussing a lot of things that are not critical - we can extract this stuff into another document at a later time.
  164
+[10:52]	<manu1>	manu: Maybe we publish JSON-LD Syntax and JSON-LD API (modulo framing)?
  165
+[10:52]	<mlnt>	manu: would it be OK for the RDF WG to proceed with the syntax and API spec and maybe take out framing (now or later)
  166
+[10:53]	<mlnt>	ivan: the only concern I have is that APIs are not in the RDF WG charter
  167
+[10:53]	<mlnt>	prototypo: I don't think it's our biggest issue... we may be making this into a bigger issue than it is.
  168
+[10:53]	<mlnt>	manu: so would you see that as a way forward? We publish JSON-LD Syntax and JSON-LD API (without framing)? I can send an e-mail to this effect if we're all okay with this approach.
  169
+[10:54]	<mlnt>	prototypo: yes, I think that's fine
  170
+[10:54]	<cygri>	q+
  171
+[10:54]	<voip-ld>	Added cygri to the speaker queue: manu1, cygri
  172
+[10:54]	<ivan_herman>	q+
  173
+[10:54]	<voip-ld>	Added ivan_herman to the speaker queue: manu1, cygri, ivan_herman
  174
+[10:54]	<mlnt>	... but prepare to be flexible and together we will find a way forward...
  175
+[10:54]	<manu1>	ack manu1
  176
+[10:54]	<voip-ld>	manu1 has the floor (to discuss the process to standardization.). The next speaker is cygri.
  177
+[10:54]	<manu1>	ack cygri
  178
+[10:54]	<voip-ld>	manu1 has the floor. The next speaker is ivan_herman.
  179
+[10:54]	<ivan_herman>	q-
  180
+[10:54]	<mlnt>	richard: the few of us that are here today can't speak for the majority of the RDF WG
  181
+[10:54]	<mlnt>	... you never know what may come up during the discussion
  182
+[10:55]	<mlnt>	... people often feel reluctant to agree on something that they don't understand
  183
+[10:55]	-->|	scor (~scor@drupal.org/user/52142/view) has joined #json-ld
  184
+[10:55]	<mlnt>	... so you will probably need to do a lot of explaining.
  185
+[10:55]	<prototypo>	+1 to Richard - expect to explain (and be flexible)
  186
+[10:55]	<mlnt>	... what this group is proposing is bigger than just a simple JSON serialization (not that that is a bad thing)
  187
+[10:56]	<mlnt>	... you have to be prepared for push-back on that
  188
+[10:56]	<mlnt>	... it takes time but is not a fundamental obstacle
  189
+[10:56]	<mlnt>	manu: I hope we get enough time to explain the stuff, I'd hate to be given only one telecon to summarize, explain and defend 18+ months of work.
  190
+[10:57]	<mlnt>	prototypo: well you have specs that can be read, that's a positive. Folks are going to have to RTFM before raising real technical issues.
  191
+[10:57]	<ivan_herman>	q+
  192
+[10:57]	<voip-ld>	Added ivan_herman to the speaker queue: manu1, ivan_herman
  193
+[10:57]	<manu1>	Topic: JSON-LD CG to RDF WG document transition
  194
+[10:57]	<manu1>	http://www.w3.org/community/reports/reqs/
  195
+[10:58]	<mlnt>	manu: there are very specific steps to transition from a CG to the WG
  196
+[10:58]	<mlnt>	... the two major things we need to do
  197
+[10:58]	<mlnt>	... 1) All JSON-LD CG members that contributed text to the spec will have to fill out the patent coverage form so that copyright and patent coverage is clear.
  198
+[10:59]	<mlnt>	... 2) We need to change the copyright from Creative Commons Attribution 1.0 to the permissive W3C license (which still allows us to fork the spec if things go terribly wrong)
  199
+[10:59]	<mlnt>	q+
  200
+[10:59]	<voip-ld>	Added mlnt to the speaker queue: manu1, ivan_herman, mlnt
  201
+[11:00]	<mlnt>	... once we transfer the document to the RDF WG, it can not be worked on by non-RDF WG members anymore.
  202
+[11:00]	<manu1>	ack manu1
  203
+[11:00]	<voip-ld>	manu1 has the floor. The next speaker is ivan_herman.
  204
+[11:00]	<manu1>	ack ivan_herman
  205
+[11:00]	<voip-ld>	manu1 has the floor. The next speaker is mlnt.
  206
+[11:00]	* gkellogg	I've already filled out the IE form
  207
+[11:00]	<mlnt>	manu: so we need to make sure that everyone in the CG that is contributing work is an invited expert or similar to be able to continue to work on this
  208
+[11:00]	<mlnt>	prototypo: you should apply via the invited expert form if you have not done so already
  209
+[11:02]	<mlnt>	manu: the only other remaing thing: how do we track issues?
  210
+[11:02]	<mlnt>	... is it ok to continue on GitHub?
  211
+[11:02]	<mlnt>	ivan: there's no process issue with this
  212
+[11:03]	<mlnt>	... only thing is that you can proof that all issues have been taken into account
  213
+[11:03]	<mlnt>	... as soon as we have a FPWD we move over the issue tracker to make collaboration easier
  214
+[11:04]	* cygri	would be quite comfortable continuing to use GitHub. it's a better issue tracker than the w3c one. only technical advantage of the w3c one is the trackbot IRC integration
  215
+[11:04]	* manu1	agrees with cygri.
  216
+[11:04]	<mlnt>	manu: should we continue to have separate telecons?
  217
+[11:04]	<taaz>	May be more efficient to do so.
  218
+[11:05]	<mlnt>	ivan: yes, I thought about that.. we might need to do this for the time being
  219
+[11:05]	<mlnt>	... but the RDF WG would need to make the final resolutions.
  220
+[11:06]	<voip-ld>	Richard Cyganiak (SIP/ekiga.net-0000000e) has left the conference.
  221
+[11:06]	<mlnt>	... on a different note: the canonilization should really be separate from JSON-LD...
  222
+[11:06]	<voip-ld>	Richard Cyganiak (SIP/ekiga.net-0000000f) has joined the conference.
  223
+[11:06]	<mlnt>	manu: yes, we separated it - and we think we have a generalized RDF graph normalization algorithm. The serialization format is in quads, which is why we have Quads in the JSON-LD API.
  224
+[11:07]	<gkellogg>	q+ has the WG considered standardizing N-Quads?
  225
+[11:07]	<voip-ld>	Added gkellogg to the speaker queue: manu1, gkellogg
  226
+[11:07]	<mlnt>	... so, yes I think we have a generic normalization algorithm now
  227
+[11:07]	<prototypo>	That would make a nice WG Note, but we aren't chartered to standardize it.
  228
+[11:07]	<prototypo>	Yes, Ivan and I agree
  229
+[11:07]	<mlnt>	ivan: this is not something that the RDF WG would publish as a spec but at least as a working group note and specify it in two years or so
  230
+[11:08]	<manu1>	ack gkellogg
  231
+[11:08]	<voip-ld>	manu1 has the floor. The next speaker is gkellogg.
  232
+[11:08]	<manu1>	ack manu1
  233
+[11:08]	<voip-ld>	manu1 has the floor (has the WG considered standardizing N-Quads?). The speaker queue is empty.
  234
+[11:08]	<prototypo>	The RDF WG will consider n-quads, but not yet
  235
+[11:09]	-->|	PatHayes (446d6fbc@gateway/web/freenode/ip.68.109.111.188) has joined #json-ld
  236
+[11:09]	<mlnt>	gregg: does the WG considers standardizing N-Quads?
  237
+[11:09]	<mlnt>	ivan: there's no consensus on this
  238
+
20  scribe-tool/scrawl-config.js
@@ -15,11 +15,26 @@
15 15
          "alias": ["danja"],
16 16
          "homepage": "http://dannyayers.com/"
17 17
       },
  18
+      "David Wood":
  19
+      {
  20
+         "alias": ["prototypo"],
  21
+         "homepage": "http://prototypo.blogspot.com/"
  22
+      },
  23
+      "François Daoust":
  24
+      {
  25
+         "alias": ["tidoust"],
  26
+         "homepage": "https://twitter.com/tidoust"
  27
+      },
18 28
       "Henri Bergius":
19 29
       {
20 30
          "alias": ["bergie"],
21 31
          "homepage": "http://bergie.iki.fi/about/"
22 32
       },
  33
+      "Ivan Herman":
  34
+      {
  35
+         "alias": ["ivan_herman"],
  36
+         "homepage": "http://www.w3.org/People/Ivan/"
  37
+      },
23 38
       "Nicolas Dufour":
24 39
       {
25 40
          "alias": ["capnemo"],
@@ -71,6 +86,11 @@
71 86
          "alias": ["manu-db", "manu1", "manu`"],
72 87
          "homepage": "http://manu.sporny.org/about"
73 88
       },
  89
+      "Richard Cyganiak":
  90
+      {
  91
+         "alias": ["cygri"],
  92
+         "homepage": "http://richard.cyganiak.de/"
  93
+      },
74 94
       "Thomas Steiner":
75 95
       {
76 96
          "alias": ["tomayac"],

0 notes on commit 74cb0ec

Please sign in to comment.
Something went wrong with that request. Please try again.