JSON-LD Telecon Minutes for 2013-10-01

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 16:25:10 UTC