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 Log
audio.ogg
Markus Lanthaler is scribing.
Manu Sporny: Agenda is there, anything else that we should add? [scribe assist by Manu Sporny]
Gregg Kellogg: Yeah, Niklas raised an issue for fromRDF got lost during a re-write [scribe assist by Manu Sporny]
Gregg Kellogg: There were no tests for it since we weren't testing that option. [scribe assist by Manu Sporny]
Manu Sporny: We need to also talk about OData alignment. [scribe assist by Manu Sporny]

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]
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: 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.