JSON-LD Telecon Minutes for 2013-08-27

The minutes from this week's telecon are now available.

http://json-ld.org/minutes/2013-08-27/

A full transcript of the meeting can be found below. Audio will take a
week or two to get on the site, my audio editor is being flaky.

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-08-27

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Aug/0090.html
Topics:
   1. Update from Vikash on GSoC
   2. JSON-LD Candidate REC Transition Discussion
   3. Testing API Options
   4. Test manifest/vocabulary updates
   5. Testing Freeze Date
Chair:
   Manu Sporny
Scribe:
   undefined
Present:
   Vikash Agrawal, Manu Sporny, Markus Lanthaler, Dave Longley,
   Niklas Lindström, Gregg Kellogg, Paul Kuykendall
Audio:
   http://json-ld.org/minutes/2013-08-27/audio.ogg

Topic: Update from Vikash on GSoC

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

Topic: JSON-LD Candidate REC Transition Discussion

http://www.w3.org/2011/rdf-wg/wiki/JSON-LD-CR-Transition-Requirements
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]
(non-substantive bug fix) Update grammar to allow blank node
   identifiers as value of @vocab
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.
(non-substantive bug fix) Support processing of documents with a
   +json media type as defined in [RFC6839]
JSON-LD 1.0 API Changes
(substantive) Support relative IRIs in @base - why is this
   substantive and JSON-LD 1.0 change is not substantive?
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.
* (substantive) Remove default value of JsonLdOption's base
   member
Markus Lanthaler:  It was set to document base, we changed it to
   be nothing - substantive.
Support for relative URLs in @base and documents that do not have
   a base value
Markus Lanthaler:  Ok, so the last part was substantive, the
   first part was not really
Ensure determinism of the Deserialize JSON-LD to RDF algorithm by
   specifying the processing order
Markus Lanthaler:  We forgot to sort properties before sorting
   them, it was a bug.
Change the default value of the use native types flag in the
   Serialize RDF as JSON-LD algorithm to false
Dave Longley:  We decided by default, we don't want to lose
   information. information loss was a bug.
all the rest are bug fixes.
Manu Sporny:  Does anyone disagree with the way these are
   classified.
No disagreement.
Manu Sporny:  I think we're good for the transition call,
   anything else?

Topic: Testing API Options

http://lists.w3.org/Archives/Public/public-linked-json/2013Aug/0076.html
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.

Topic: Test manifest/vocabulary updates

http://lists.w3.org/Archives/Public/public-linked-json/2013Aug/0084.html
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...
...generalized rdf, etc.
Error: (IRC nickname not recognized)[Tue 11:07] <m4nu> m4nu:
   everything looks good, anything that's missing?
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.

Topic: Testing Freeze Date

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.

-- 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, 27 August 2013 17:07:05 UTC