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