Re: JSON-LD Telecon Minutes for 2013-10-01

One thing I forgot to bring up on the JSON-LD call is that final implementation reports should probably be sent to public-rdf-comments@w3.org. For Turtle, we maintain an Implementations list with coverage [1]. For JSON-LD, I think it's pretty redundant, as that information is already on the EARL report in more detail.

Informally, implementation reports have been checked into GitHub, but having the developer submit it to a public list would be a good idea. Also, if sending a link, please ensure that it is immutable (i.e., to a specific commit) so that future reports aren't confused with an earlier version.

Gregg Kellogg
gregg@greggkellogg.net

[1] http://www.w3.org/2011/rdf-wg/wiki/Turtle_Candidate_Recommendation_Comments#c18

On Oct 1, 2013, at 9:24 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Thanks to Markus for scribing! The minutes from this week's telecon are
> now available.
> 
> http://json-ld.org/minutes/2013-10-01/
> 
> A full transcript of the meeting can be found below. Audio for the call
> is available at the link provided above.
> 
> -------------------------------------------------------------------
> JSON-LD Community Group Telecon Minutes for 2013-10-01
> 
> Agenda:
>   http://lists.w3.org/Archives/Public/public-linked-json/2013Sep/0093.html
> Topics:
>   1. Candidate Recommendation Feedback
>   2. Spec Bug with useRdfType flag
>   3. OData Alignment
>   4. Updating the Implementation Report
>   5. W3C Hosted Version of Test Suite
>   6. Plan for Proposed Recommendation
> Resolutions:
>   1. JSON-LD 1.0 and the API will remain in Candidate Rec for an
>      additional week to fix a bug in the spec related to the
>      useRdfType flag and add an additional test. After the spec text
>      has been fixed, and a test created, implementers will be required
>      to file new implementation reports. Once they have done so, the
>      specs will exit CR.
> Action Items:
>   1. Manu to write up instructions on running the Candidate
>      Recommendation Test Suite.
> Chair:
>   Manu Sporny
> Scribe:
>   Markus Lanthaler
> Present:
>   Markus Lanthaler, Manu Sporny, Gregg Kellogg, Niklas Lindström,
>   Paul Kuykendall, Dave Longley, David I. Lehn, Stian Soiland-Reyes
> Audio:
>   http://json-ld.org/minutes/2013-10-01/audio.ogg
> 
> Markus Lanthaler is scribing.
> Manu Sporny:  Agenda is there, anything else that we should add?
> Gregg Kellogg:  Yeah, Niklas raised an issue for fromRDF got lost
>   during a re-write
> Niklas Lindström:
>   https://github.com/json-ld/json-ld.org/issues/91#issuecomment-25046309
> Gregg Kellogg:  There were no tests for it since we weren't
>   testing that option.
> Manu Sporny:  We need to also talk about OData alignment.
> 
> Topic: Candidate Recommendation Feedback
> 
> Manu Sporny:  we had two basic items - useRdfType bug and OData
>   Alignment
>   ... anyone know of any other CR feedback we got?
> No other CR feedback from implementers.
> 
> Topic: Spec Bug with useRdfType flag
> 
> Manu Sporny: Let's take Niklas' issue first, which is here -
>   https://github.com/json-ld/json-ld.org/issues/91#issuecomment-25046309
> Niklas Lindström:  we used to have an option in the serialize RDF
>   to JSON-LD algorithm to not use @type but rdf:type
> Gregg Kellogg:  it was called useRdfType
> Niklas Lindström:  I mainly need that to ensure that the value is
>   always an array (I can't control that for @type)
>   ... to keep the shape of the data deterministic
>   ... another use case might be to have the type as an object
>   itself
>   ... but that's more a speculative demand
> Manu Sporny:  looking at the commits it definitely looks like an
>   unintended bug
>   ... if that's the case, we should be able to fix this without
>   going through another LC/CR
> Manu Sporny:  the other thing is the question markus raised.. if
>   we introduce this: do we look for @type or rdf:type
> Niklas Lindström:  I think the question is interesting in it's
>   own right
>   ... the data may be produced in different ways so we always
>   have to deal with this
>   ... and there's currently no way to turn rdf:type to @type or
>   vice versa AFAIK
> Gregg Kellogg:  if we put this back in, it would make sense to
>   write tests for it
>   ... not sure what the consequences are
> Manu Sporny:  yeah, that's a grey area.. people could argue we
>   introduce a new feature that wasn't there (tested) before
>   ... meaning we would need to go through another LC
> Markus Lanthaler:  we never really discussed @type or rdf:type
>   before. [scribe assist by Manu Sporny]
> Gregg Kellogg:  I implemented it, I thought the text went in that
>   resolved that. [scribe assist by Manu Sporny]
> Gregg Kellogg:  Did we have spec text to deal w/ this issue?
>   [scribe assist by Manu Sporny]
> Niklas Lindström: ..
> 
> https://github.com/json-ld/json-ld.org/commit/956c76f99e6bd60a0742b5b29c6061a838bbb3ba#L0L3410
> Markus Lanthaler:  How does the consumer of the data know whether
>   to look for @type or rdf:type? [scribe assist by Manu Sporny]
> Gregg Kellogg: [[ 3.6) If property is rdf:type and the useRdfType
>   option is not present or false:
> Gregg Kellogg: 3.6.1) Append the string representation of object
>   to the array value for the key @type, creating an entry in value
>   if necessary. ]]
> Gregg Kellogg:  another option could be to move this out to a
>   separate (CG) spec
> Niklas Lindström:  I think I agree
> Paul Kuykendall: The latest reference to useRdfType I could find
>   in the spec itself was
>   http://json-ld.org/spec/ED/json-ld-api/20121225/
> Markus Lanthaler:  Paul, here's the link to the commit in which I
>   removed it accidently:
> 
> https://github.com/json-ld/json-ld.org/commit/956c76f99e6bd60a0742b5b29c6061a838bbb3ba#L0L3410
> Gregg Kellogg:  perhaps we do this in a next version or in a
>   separate spec
> Niklas Lindström:  that would be an issue for me
> Gregg Kellogg:  I was suggesting to have something like a
>   supplementary note or CG document not really wait for a 1.1 spec
> Niklas Lindström:  Having it in the current algorithm would make
>   it clear that RDF-to-JSON-LD may contain rdf:type and/or @type
> Gregg Kellogg:  we could just as well have options in
>   expand/compact to keep @type as array
> Niklas Lindström:  right.. and in principle I would prefer that
> Markus Lanthaler:  The question I asked myself is - do we need to
>   specify all of this? Every implementation can do what it wants.
>   Do we want to require every implementation to do that? [scribe
>   assist by Manu Sporny]
> Markus Lanthaler:  If we do that, we have to update the test
>   suite. [scribe assist by Manu Sporny]
> Markus Lanthaler:  Even if that option is not in the standard,
>   all implementations can support it anyway. The API doesn't even
>   have toRDF and fromRDF methods anymore. [scribe assist by Manu
>   Sporny]
> Niklas Lindström:  Having the option lets people know that there
>   is variability there. [scribe assist by Manu Sporny]
> Markus Lanthaler:  I agree, but I don't find it important enough
>   to have to go through another LC. [scribe assist by Manu Sporny]
> Manu Sporny:  there are multiple options
>   ... a) re-introduce useRdfType and nothing else
>   ... b) also add tests, that would probably mean another LC
>   ... c) put it in a different spec/note because we don't have
>   an API for it anyway at the moment
> Niklas Lindström:  the problem with that is that I expect to
>   encounter this issue in a Java implementation or something.. so
>   it affects the algorithms but not necessarily the API
> Manu Sporny:  the fourth option is d) re-introduce a variation of
>   useRdfType which would allow us to go through another LC
> Gregg Kellogg:  my suggestion is to update the spec to include
>   useRdfType but do not add tests
> Gregg Kellogg:  we should probably discuss this with W3C staff
> Manu Sporny:  we are ready to leave CR
>   ... we'll try to fix this bug if it doesn't mean another LC
>   ... otherwise we'll fix it in the next version
>   ... would that be ok Niklas?
> Niklas Lindström:  yes
> Manu Sporny:  so is the consensus to re-introduce useRdfType and
>   nothing else (no tests)?
> Gregg Kellogg:  I think we should talk about the long term goal
>   of the test suite
>   ... we should have a way to update it as we did with RDFa
> Manu Sporny:  I think so.. we should be able to react to bugs
>   etc.
>   ... we have a frozen test suite for going through CR
>   ... but in a couple of months we should be able to add tests
>   without going through the whole process again
> Paul Kuykendall:  I have a few concerns with that approach
>   ... it's a bit of handwaving
>   ... we have a lot of options and not all of them are tested
>   properly
> Manu Sporny:  if that's the reaction, we rip the option out again
> Markus Lanthaler:  We have control over most of the
>   implementations in the implementation report, can't we simply add
>   the test and run the reports again? [scribe assist by Manu
>   Sporny]
> Markus Lanthaler:  We do say that the group will decide when the
>   test suite is of good quality. [scribe assist by Manu Sporny]
> Markus Lanthaler:  1st of October is the earliest date, doesn't
>   mean we have to exit today. [scribe assist by Manu Sporny]
> Manu Sporny:  excellent point
>   ... I think that gives us a way out
>   ... we fix the bug in the spec, add a test, wait for
>   implementations
> Paul Kuykendall:  I like that
> 
> PROPOSAL: JSON-LD 1.0 and the API will remain in Candidate Rec
>   for an additional week to fix a bug in the spec related to the
>   useRdfType flag and add an additional test. After the spec text
>   has been fixed, and a test created, implementers will be required
>   to file new implementation reports. Once they have done so, the
>   specs will exit CR.
> 
> Paul Kuykendall: +1
> Manu Sporny: +1
> Gregg Kellogg: +1
> Niklas Lindström: +1
> Dave Longley: +1
> Markus Lanthaler: +1
> David I. Lehn: +1
> 
> RESOLUTION: JSON-LD 1.0 and the API will remain in Candidate Rec
>   for an additional week to fix a bug in the spec related to the
>   useRdfType flag and add an additional test. After the spec text
>   has been fixed, and a test created, implementers will be required
>   to file new implementation reports. Once they have done so, the
>   specs will exit CR.
> 
> Topic: OData Alignment
> 
> Manu Sporny: Feedback from Michael Pizzo at Microsoft on OData
>   alignment -
>   http://lists.w3.org/Archives/Public/public-linked-json/2013Sep/0079.html
> Manu Sporny: so, change stuff like - "@type" to "@jsonld.type"
>   and "@context" to "@jsonld.context"
> Manu Sporny:  the OData community is asking us to change all
>   keywords to use a "@jsonld." prefix.
>   ... we can do that already because we can alias keywords
>   ... it seems part of it is not understanding that JSON-LD is
>   lower-level than OData and part is not understanding keyword
>   aliasing in JSON-LD (or the JSON-LD Context in general)
>   ... prefixing everything with a prefix containing a dot makes
>   it difficult to work with in JavaScript. Additionally, the prefix
>   could be ignored entirely by developers that alias it to
>   something else.
>   ... the other thing is that OData could be implemented on top
>   of JSON-LD since it's more of a schema and less of a markup
>   language.
> Gregg Kellogg:  just wanted to say that putting a dot in a key is
>   incompatible with MongoDB
>   ... and as Manu said, every key except @context can be aliased
>   ... that being said, I'm sympathetic to having some kind of
>   namespacing mechanism.
> Dave Longley:  another way to look at is is to say that
>   "@jsonld." is the default namespace so we don't need to change
>   anything
> Manu Sporny:  I have trouble understanding what problem we're
>   trying to address here. Why do we need a standard namespacing
>   scheme for metadata languages?
>   ... why would someone like to layer meta-languages beside each
>   other? Seems like a complex solution to a problem that we haven't
>   encountered in the 4 years that we've been developing this spec.
>   Even if someone had this problem, they are probably
>   overengineering the solution to it.
> Gregg Kellogg:  that's the same question as Microdata and RDFa in
>   HTML
> Niklas Lindström:  I agree. Seems like they are trying to convert
>   JSON to XML but we've seen that that doesn't solve any problem
> Paul Kuykendall:  Our company  tried to go down the OData route
>   early on
>   ... some of their features (vocabs etc.) do allow to be
>   aligned with RDF
>   ... so that may be the motivation behind it
> Dave Longley:  you can already do what they want to do... you
>   have a context in JSON-LD defining everything. Then you just use
>   the OData JSON-LD Context.
> Paul Kuykendall:  exactly, that's the reason why we did chose
>   JSON-LD - flexibility to do what Michael is asking for.
> Manu Sporny:  nothing stops Microsoft layering OData on top of
>   JSON-LD
>   ... they can simply use the @odata. prefix
>   ... it's not clear what changing all properties to use a
>   @jsonld. prefix would buy us other than a standard mechanism for
>   metadata languages to namespace metadata language-specific
>   keywords. None of the people using JSON-LD seem to have this
>   problem right now.
>   ... on the other hand, making this change would break existing
>   JSON-LD content out there, it would cause us to go through
>   another Last Call and CR, delaying the process by months. It
>   would also make the markup problematic when using it with
>   document-based databases like MongoDB. So, there are a number of
>   downsides with no clear upside.
> Paul Kuykendall:  I think the group is right.. it is a solution
>   to a non-problem
> Manu Sporny:  let's try to get Microsoft on a call to talk about
>   it, maybe there is something deeper here that we're missing.
> Gregg Kellogg:  this is not unlike the activity streams group
>   which doesn't want to use JSON-LD's media type and also doesn't
>   want to include a @context property
> Dave Longley:  looks like they want to avoid conflicts between
>   keywords and other properties.. that's exactly what the context
>   is for in JSON-LD.
> 
> Topic: Updating the Implementation Report
> 
> Manu Sporny:  we need to wait for the updated implementation
>   report, we need to add the useRdfType test.
> Gregg Kellogg:  we are also waiting on an updated report from the
>   Java implementation
>   ... we'll probably get one by next week
> Gregg Kellogg: http://json-ld.org/test-suite/reports/
> Gregg Kellogg:  the current implementation report lists 7
>   implementations
>   ... 6 pass 100% of the tests
> Stian Soiland-Reyes: (just slightly related) I have just updated
>   the jsonld-java bindings for Jena btw
> Manu Sporny: Great, thanks stain, that's very helpful to know
> Niklas Lindström:  I might use this additional week to submit a
>   report of my implementation as well
> Gregg Kellogg:  It would be great if we would have an
>   implementation in C
> Dave Longley:  we have an old C++ implementation if someone wants
>   to update it
> Paul Kuykendall:  unfortunately I can't submit a report for our
>   C# implementation
> 
> Topic: W3C Hosted Version of Test Suite
> 
> Gregg Kellogg:  there's still the question if we want to run the
>   final test suite from w3.org instead of json-ld.org
> Manu Sporny: Discussion related to static location of JSON-LD
>   test suite.
> Niklas Lindström: .. just recalled this Java-based implementation
>   of JSON-LD: http://semarglproject.org/ Not sure about its status,
>   but the RDFa 1.1 support is solid. Might want to ping Lev Khomich
>   about a report.
> Discussion about how to freeze a working version of the JSON-LD
>   test suite.
> Markus Lanthaler:  Niklas,
>   http://semarglproject.org/conformance.html: Works in JSON-LD-RDF
>   Converter mode. At this moment only supports conversion to RDF.
> Gregg Kellogg: We could update documentation here:
>   http://www.w3.org/2013/json-ld-tests/
> Gregg Kellogg:  or we update
>   http://json-ld.org/test-suite/reports/ to include the
>   instructions and mirror that
> 
> ACTION: Manu to write up instructions on running the Candidate
> Recommendation Test Suite.
> 
> Gregg Kellogg: actually, not /reports, just /test-suite, which
>   could include /reports/
> Markus Lanthaler:  Gregg, I meant /reports because it doesn't
>   link to anything else on json-ld.org
> 
> Topic: Plan for Proposed Recommendation
> 
> Manu Sporny:  I think our plan is to delay exiting CR by at least
>   a week to re-introduce useRdfType. Then, we'll get all of the
>   implementation reports together. Then we'll move to have the RDF
>   WG move the work to Proposed Rec. We don't have many changes to
>   the spec, so that should be fast. Then there is the mandatory 7
>   day waiting period, then meeting with W3C Management to approve
>   the publication as a Proposed Rec. When W3C publishes the
>   Proposed Recommendation, we'll have to wait 4 weeks for the votes
>   to trickle in. After the votes are in, we'll have a W3C
>   Recommendation... we already have the minimum votes to make it, I
>   believe. So, we should have a W3C Recommendation within 6-8 weeks
>   from now.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Meritora - Web payments commercial launch
> http://blog.meritora.com/launch/
> 
>

Received on Tuesday, 1 October 2013 23:54:31 UTC