Vikash Agrawal: This week I kept working on the LinkedIn app, can't show any of the updates now.

Vikash Agrawal: I've been needing some JSON documents of people's LinkedIn profiles.

Vikash Agrawal: My LinkedIn profile is not very detailed, need something more detailed.

Vikash Agrawal: I'm not sure what things like "interest", "position", "skill" should be linked to.

Vikash Agrawal: Dave Longley and I had a good talk about things that I needed to change. For example, schema.org and companies and organizations.

Vikash Agrawal: Also talked about what the data in JSON-LD should look like.

Manu Sporny: Let me know when to send you my JSON data.

Vikash Agrawal: This is the last week of work on code, I need to move on to documentation and extra bonus items.

Manu Sporny: How many weeks are left for you?

Vikash Agrawal: around 3-4 weeks.

Vikash Agrawal: Via my proposal, documentation is next. I think I'll finish the LinkedIn app this week, I'd like to keep working on other stuff, not necessarily documentation.

Vikash Agrawal: I think I need to write the schema... it's one of my weak points.

Manu Sporny: Ok, so the plan is to work on the schema.org JSON-LD Context.

Vikash Agrawal: Ok, sounds good.

Manu Sporny: You should focus on generalizing the schema.org JSON-LD Context and generalizing the Creator tool.

Vikash Agrawal: Yes, generalizing LinkedIn app is difficult.

Markus Lanthaler: just checked, schema.org doesn't have CORS enabled

Manu Sporny: Let's try to build the tool to translate schema.org in Javascript so other people can hack on it.

Markus Lanthaler: http://schema.rdfs.org/ is CORS enabled

Markus Lanthaler: so you might wanna use that instead

Manu Sporny: So we need to discuss this: http://www.w3.org/2011/rdf-wg/wiki/JSON-LD-CR-Transition-Requirements#Documentation_of_changes

Dave Longley: m4nu: primarily we need to make sure that all the changes i've marked as non-substantive bug fixes/editorial

Vikash Agrawal: you can find the complete definition of schema.org in RDFa (usable with greenturtle) at http://schema.org/docs/schema_org_rdfa.html HTH [scribe assist by Markus Lanthaler]

Dave Longley: m4nu: are ok, i need to be reminded how these things are bug fixes

Markus Lanthaler: s/vikash: you/vikash, you/

Dave Longley: m4nu: as we are reading these, if someone thinks the changes aren't just bug fixes that means CR is off

Vikash Agrawal: mlnt, I think with an AJAX call to http://schema.rdfs.org/all.json things can ease out

Markus Lanthaler: yeah, but as niklas already said, it's outdated

Dave Longley: All implementations were doing it already, we didn't say that you could do that in the spec.

Dave Longley: m4nu: [discussion of non-substantive changes]

Dave Longley: Almost everywhere we allow bnode IDs in the specs, we look for a colon, we weren't clear in the spec that you could use a blank node here.

Niklas Lindström: This aligned w/ HTML, TURTLE, etc. We always intended this to behave in the general way it works elsewhere.

Manu Sporny: ok, so changing to (non-substantive bug fix) Support relative IRIs in @base

Dave Longley: Yes, we didn't get strong comments on this when the change was made, that's always the way it was expected to work.

Markus Lanthaler: It was set to document base, we changed it to be nothing - substantive.

Markus Lanthaler: Ok, so the last part was substantive, the first part was not really

Markus Lanthaler: We forgot to sort properties before sorting them, it was a bug.

Dave Longley: We decided by default, we don't want to lose information. information loss was a bug.

Manu Sporny: Does anyone disagree with the way these are classified.

Manu Sporny: I think we're good for the transition call, anything else?

Gregg Kellogg: The API Options are done by just adding an "option" member to each test entry, and that entry has a value that has it's own properties for each option we're testing. Or, in some cases, where it indicates that an option should be used with some specification that is yet to be created. For document loader implementation, we need to define how it must behave.

Gregg Kellogg: We need to talk about how to handle errors. We have one test entry as a placeholder. We could fold the error test cases into regular test cases for each algorithm.

Gregg Kellogg: Markus thinks it might be simpler to keep errors separate to make an easier to implement test runner.

Gregg Kellogg: I think I put in the last test for all specified error conditions in Expand algorithm in addition to context algorithms last night.

Gregg Kellogg: There are 3 algorithms and context tthat call out specific error cases, there is a test for each of them. There are expand errors, they have tests. There are other algorithms that could be invoked during expansion.

Gregg Kellogg: We have complete test coverage up to that point.

Gregg Kellogg: The other issue which has been created is how the Context entry should be treated. This is pertinent because we had a number of context documents which were simply empty documents.

Gregg Kellogg: A document with an empty object is an error condition, we didn't intend to do that.

Gregg Kellogg: if the "context" argument provides an empty context, then it's not an error. The entries in the manifest are defined to be of type @id, they're treated as IRIs, therefore if the document were expanded, they'd be absolute IRIs, then it's clear to me that the meaning of that IRI is passed as the context, and that would open the link up and read it.

Gregg Kellogg: What would we do if we had to test passing a context that wasn't an IRI, but an object, etc.

Gregg Kellogg: Markus suggested that all of those tests can be done via the IDL test platform.

Gregg Kellogg: I think that's the way to do it.

Gregg Kellogg: I think if we wanted to do it inline, we'd pass a literal value for context with a datatype that would allow it to be used that way.

Gregg Kellogg: that's probably not ideal.

Manu Sporny: wrt. the WebIDL test cases, is that possible?

Dave Longley: I don't know how to hook it into the harness to see if it's possible. I think we'd create more tests so that a test runner would know if it would have to run through the API.

Dave Longley: https://travis-ci.org/digitalbazaar/jsonld.js/jobs/10559014

Dave Longley: I don't know if the WebIDL tests would be where we run this.

Dave Longley: We now run automated tests against W3C JSON-LD WebIDL test suite

Markus Lanthaler: dlongley, here's how you can add other tests: http://darobin.github.io/test-harness-tutorial/docs/using-testharness.html

Dave Longley: The only thing that tests is to make sure we have the proper stuff in the object.

Markus Lanthaler: We can create our own tests using this test harness.

Dave Longley: This just tells you how to use their test harness to write arbitrary tests.

Dave Longley: What I'm saying is that all we'd do is create another manifest and you only run those tests if you run the IDL-based API.

Manu Sporny: So, we'd create some test harness to run it through an API... you can use whatever test harness you want.

Gregg Kellogg: This raises another question on reporting on the IDL tests... are they testing the API design, or are they intended to be used for implementations.

Gregg Kellogg: It would make it difficult to show two conforming implementations.

Dave Longley: The two conforming implementations would just be two things written in JavaScript.

Dave Longley: We just need to ensure that we're testing API options.

Dave Longley: We need to test to make sure they're doing the right thing wrt. the spec.

Dave Longley: We should test what the API options do, but they probably won't use the WebIDL stuff.

Markus Lanthaler: We were just talking about adding something to the IDL test suite.

Markus Lanthaler: I think we might want to have one or two tests added to the IDL tests.

Dave Longley: Where are we going to put that information.

Dave Longley: I don't know how we're avoiding the issue of inlining context or avoiding the problem of having to put context inline.

Gregg Kellogg: In that case, we would also need to support inline input documents.

Gregg Kellogg: We could use a literal form for the value with a datatype that says it's serialized JSON.

Markus Lanthaler: If we test it once, that's enough for the API. The algorithms just need to handle the input it receives.

Markus Lanthaler: Whether or not you can pass in a context definition in raw object form, it's not really important to the main manifest. Let's just tack that one test onto the end of the WebIDL stuff.

Dave Longley: So, we want to have a single test for passing things in inline?

Markus Lanthaler: We had a discussion where we had an object passed directly in.

Markus Lanthaler: We could add something to the IDL test that does both.

Dave Longley: I'm trying to figure out what "add that test to the IDL" means.

Markus Lanthaler: Let's just update the page on json-ld.org.

Dave Longley: We can do that, I guess we're not that concerned w/ others implementing the IDL interface.

Manu Sporny: It's not that important that we need to test this.

Markus Lanthaler: Simplest thing is to just not test it, let's just leave the test out.

Dave Longley: We have a minimum set of tests for the API, so we're good.

Gregg Kellogg: I don't think we need to do WebIDL tests.

Dave Longley: We could have a single test that says you pass WebIDL. It'll show that we have a JavaScript implementation.

Manu Sporny: Let's not do that, no need to do that.

Paul Kuykendall: Are we going to have tests that support both native as well as more standard RDF types?

Gregg Kellogg: Yes, we've added a way to describe those options in the manifest, we need to create tests that use those options. We need a test for each place each option is called out in the spec.

Paul Kuykendall: Are they using native?

Dave Longley: Native is off by default... doubles would be hard to test.

Paul Kuykendall: ok, thanks.

Paul Kuykendall: Yeah, standard C# double is not safe because of rounding issues. There is an IEEE-specific type that has to be used in order to support the xsd:double.

Gregg Kellogg: We could consider just changing the value being tested so it's in the range being supported by standard double packages.

Paul Kuykendall: Testing so that it's xsd:double is fine.

Gregg Kellogg: Since we reference a vocabulary, we should have the vocabulary defined. So there is a TURTLE vocab document and that is translated into JSON-LD and into RDFa.

Gregg Kellogg: http://json-ld.org/test-suite/vocab.html

Gregg Kellogg: As a result, if you go to http://json-ld.org/test-suite/vocab you will get the HTML+RDFa definition.

Gregg Kellogg: There is an attempt to do some content negotiation based on the accept type.

Gregg Kellogg: If someone can go and look at it and take a look, it would be nice to return the JSON-LD and Turtle versions of that.

Gregg Kellogg: These do define all of the terms in the test manifest. Positive/Negative/Syntax/Eval tests. Compact, flatten, it's all in there.

Gregg Kellogg: there are definitions for all of the properties that are used. The properties we're using are the RDF versions. So you'll see an 'input' property... it's an alias for mf:action - test manifest for RDF used elsewhere. This can be processed truly as RDF, in which case we needed other options that are not in the standard test manifest for base, compact arrays, expand context, produce...

Gregg Kellogg: nope, it's all there.

Gregg Kellogg: One thing we're not testing for is the processing mode, however we don't expect to override that. The default is JSON-LD 1.0. This is the flag that is sent in via the Test Runner that puts the processor in a strict RDF mode. Normalization would probably not be set to JSON-LD 1.0, it would be something else.

Manu Sporny: What do we want to do with the test suite freeze date?

Gregg Kellogg: TURTLE froze before CR.

Gregg Kellogg: RDFa froze at the very end of CR.

Gregg Kellogg: We do need to come up with a time where the test suite is ready and tag it. Maybe when we do the call for implementations. We can re-tag later. We should freeze and then fix bugs. Reports would be against tagged version of URI for test manifest.

Manu Sporny: Let's freeze at CR.

Gregg Kellogg: The base URI for tests is JSON-LD/test-suite.

Gregg Kellogg: For TURTLE it's something under the TR-space. If we want to do that, we would change the instructions so that the test location should point to a static location.

Gregg Kellogg: Let's just keep it at json-ld.org.

Dave Longley: let's just keep it there on json-ld.org

Manu Sporny: So we're going to freeze the test suite when the CR publication happens.

Manu Sporny: Telecon for next week is canceled.