JSON-LD Telecon Minutes for 2013-05-14

Thanks to Paul Kuykendall for scribing! The minutes from this week's
telecon are now available.

http://json-ld.org/minutes/2013-05-14/

Full text of the discussion follows including a link to the audio
transcript:

--------------------
JSON-LD Community Group Telecon Minutes for 2013-05-14

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013May/0044.html
Topics:
   1. Implementation Updates
   2. RDF-ISSUE-129: Lossless conversion
   3. RDF-ISSUE-128: Mandatory profiles
Resolutions:
   1. Add issue markers to the 2nd Last Call for JSON-LD
      Algorithms and API to warn about how the useNativeTypes flag and
      algorithm might change, and to also warn about the details of
      referencing the DOM-WHATWG spec wrt. Futures may change.
Chair:
   Manu Sporny
Scribe:
   Paul Kuykendall
Present:
   Manu Sporny, Paul Kuykendall, Gregg Kellogg, Sandro Hawke,
   Niklas Lindström, Stian Soiland-Reyes
Audio:
   http://json-ld.org/minutes/2013-05-14/audio.ogg

Paul Kuykendall is scribing.
Manu Sporny:  Any updates to the agenda?
Gregg Kellogg:
   https://github.com/json-ld/json-ld.org/issues/246#issuecomment-17773737
Gregg Kellogg:  new issue brought up from link above

Topic: Implementation Updates

Gregg Kellogg:  ruby implementation released some minor problems
   fixed (typos and missing steps)
   ... waiting to fix missing steps for talking with markus and
   others
Gregg Kellogg:  more tests need to be added to look for errors
   ... sandro put out some additional tests as well
Manu Sporny:  freeze test suite before going to CR
Sandro Hawke:  can add tests after we go to CR
Sandro Hawke:  we need to get people running the test suite
Gregg Kellogg:  important for json-ld to be handled by most
   important implementations, jenna, etc.
Stian Soiland-Reyes: https://github.com/jsonld-java/jsonld-java
   has been receiving minor patches recently by ansell and tristan
Niklas Lindström:  no major movement on our part, mainly working
   with turtle
Niklas Lindström: his original source:
   https://github.com/tristan/jsonld-java
Manu Sporny:  Andy stopped working on the processor about 6
   months ago because the spec was in too much flux. Tristan is
   working on getting it in shape in the near future
Manu Sporny:  Working on the JSON-LD normalization now. Should be
   in good shape for a Java implementation in the next few months

Topic: RDF-ISSUE-129: Lossless conversion

Manu Sporny: http://www.w3.org/2011/rdf-wg/track/issues/129
Sandro Hawke:  Working on some RDF issues in patch, such as when
   literals match case, etc. We were losing information such that
   triples don't match themselves often. example in email.
   ... Challenge with JSON being underspecified in numbers,
   different parsers have different parsing mechanisms.
   ... Basically, we might as well convert all native number
   types to json numbers
   ... don't convert decimal as most people use it to flag they
   care about exact precision
Manu Sporny:  we had a lot of conversations regarding
   round-tripping with json-ld
   ... idea of round tripping issues is well known. Don't use use
   datatypes flag in order to ensure proper data round-tripping.
Sandro Hawke:  add editorial comment to highlight the warning
   about round-tripping data issues.
Manu Sporny:  there are some comments, but they could be
   highlighted better. We need to be careful to not to overly
   restrict data conversion 32/64 bit conversions, etc.
Sandro Hawke:  don't pass around json-ld with native numbers
   unless you really don't care about your integrity
Manu Sporny:  we tried to be specific in guidance. It needs to be
   added to the spec. This situation is very application specific
Manu Sporny:  when data is published on the web today many assume
   that machine is 32bit capable.
Manu Sporny:  most web developers won't convert numbers by
   converting to int, etc. and marking it with the xml type
Sandro Hawke:  if you use native forms then clients may get the
   wrong data, should use expanded form.
Paul Kuykendall:  I do think it's important that we say something
   in the spec, it might get lost - we're doing banking/financial
   apps - datatypes are very important wrt. numbers. [scribe assist
   by Manu Sporny]
Paul Kuykendall:  It'll be good for our data consumers to know
   that this is an issue. [scribe assist by Manu Sporny]
Sandro Hawke:  2 parts of proposal. first part is editorial. Use
   native types is "do what I mean, but I accept errors"
   ... turn them into native numbers.
Sandro Hawke:  the other part would be it alwas comes back as a
   double
Gregg Kellogg:  I wonder if the flag is in the wrong place
Gregg Kellogg:  perhaps there should be an expansion flag such
   that when we expand we turn all numeric data types into ? data
   types so that the consumers can choose how data is handled
Sandro Hawke:  I like that
Gregg Kellogg:  it is possible to use numerical representation
   and not loose type/precision information on conversion.
Manu Sporny:  I have a concern about if it is round-tripable
   between rdf->jsonld->rdf
   ... you will loose information when transforming back and
   forth to json-ld
Sandro Hawke:  if you don't want to lose info, don't use native
Manu Sporny:  you never lose type information if you round-trip.
Sandro Hawke:  yes you do, <missed example>
Gregg Kellogg: Turtle 1 = {"@value": 1, "@type": "xsd:int"}
Gregg Kellogg:  you can do a transformation and retain the type
   ... the precision could be changed, but the type is retained
   ... rdf - json is always using expanded form
   ... only on compaction will the type information be lost
Manu Sporny:  I don't like that we lose type information between
   different types. It's a non-starter
Sandro Hawke:  Wait, I thought you were saying that type
   information is preserved, isn't that what I'm proposing?
Manu Sporny:  What I mean is that it is possible for the
   developers to better manage type conversion with the current
   approach. Markus' changes lose some of that fidelity.
Gregg Kellogg:  add option so that the developer can choose if
   string representation or native form is used via an option flag
   if the types match.
   ... current spec has converting to string that are missing the
   data type.
Manu Sporny:  we need to discuss this more with Markus and Dave
   on the call to talk about the changes being made. The changes
   have cascading effects
Manu Sporny:  if we do make this change it would have a
   non-trivial change forcing another last-call
Gregg Kellogg:  we haven't already entered 2nd last call
Manu Sporny:  we can add an additional at-risk marker to keep us
   from having to enter a 3rd last call
Gregg Kellogg:  I'll make sure it is brought up
Manu Sporny:  need to mark it as "needs community input"
Sandro Hawke:  I haven't seen that reference, but it makes sense.
   please look for that reference
Manu Sporny:  We will try and fix these issues and add an issue
   marker highlighting the issue, and bring it up at the RDF working
   group
Sandro Hawke:  we many need to refer to a different spec
   regarding futures - the DOM WHATWG one might change.
Sandro Hawke:  hard requirement is to refer to stable things. it
   is hard to argue that the "living spec" is stable
   ... not saying we change the reference, but change how we use
   the reference
Manu Sporny:  We don't actually reference the Futures spec
   directly. We only use the Future concept in our spec, not the API
   itself.
Sandro Hawke:  if they change Futures, then every piece of
   software using futures would be broken and have to change
Manu Sporny:  Being pedantic, but the spec wouldn't change, just
   the implementation.
Sandro Hawke:  The director probably won't be okay with that. You
   shouldn't build on specs that are not stable
   ... We have to hard-code it with the current view of futures
   so that if it changes, we use the old version of futures
Manu Sporny:  adding two issues to the spec and will publish next
   tuesday
   ... that gives us the chance to avoid al 3rd last-call

PROPOSAL: Add issue markers to the 2nd Last Call for JSON-LD
   Algorithms and API to warn about how the useNativeTypes flag and
   algorithm might change, and to also warn about the details of
   referencing the DOM-WHATWG spec wrt. Futures may change.

Manu Sporny: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Sandro Hawke: +1
Niklas Lindström: +1
Stian Soiland-Reyes: +1

RESOLUTION: Add issue markers to the 2nd Last Call for JSON-LD
   Algorithms and API to warn about how the useNativeTypes flag and
   algorithm might change, and to also warn about the details of
   referencing the DOM-WHATWG spec wrt. Futures may change.

Gregg Kellogg:  I think this should include how the useNativeType
   flag impacts the misuse of type conversion.

Topic: RDF-ISSUE-128: Mandatory profiles

Manu Sporny:  Peter Ansell is asking us to make certain profiles
   mandatory on the server and client. He is saying that this is an
   inter-operability issue, which it is. We also can't force people
   into interop, and we do want people to be able to dip their toes
   into JSON-LD w/o being hit over the head by a requirement like
   this.
Manu Sporny: http://www.w3.org/2011/rdf-wg/track/issues/128
Manu Sporny:  There is a thought that Peter might have missed the
   fact that we can't force people to do things they don't want to
   do by requiring a certain set of operations.
   ... if we require expanded, flattened, and compacted, then we
   increase the burden of server developers such that they may not
   want to implement the spec
Manu Sporny:  we don't want the community to come along and say
   you're doing it wrong by not supporting everything in the spec
   ... there are good intentions but it could hinder large
   corporations from dipping their toes into json-ld
   ... it hurts incremental conformance of the spec
Gregg Kellogg:  the proposal uses should instead of must
Paul Kuykendall:  I think it's important that profiles are not
   mandatory - we're just implementing just enough to get us going.
   At this point, we don't need mandatory profiles. We'd like to be
   able to say we're using JSON-LD in our marketing docs, but at
   this point, we don't have the need to do anything more than
   expand (we don't support compact / flattened). Having that club
   out there would be a... [scribe assist by Manu Sporny]
Manu Sporny: ...detriment to us.
Paul Kuykendall:  We intend to use the other formats, but at this
   point, we're trying to just get it done. [scribe assist by Manu
   Sporny]
Paul Kuykendall:  While expand was a pretty big undertaking,
   compact and flatten really add a lot of extra overhead that
   doesn't buy us any real business value. It will in the future,
   but right now it doesn't provide us anything. Having that club
   out there wouldn't be good to us. [scribe assist by Manu Sporny]
Manu Sporny:  what Paul just said is the same feedback as what
   the we've gotten from larger companies in private
   ... 'should' is fine verbiage rather than 'must' for
   implementation of spec
Gregg Kellogg:  <<< pk/ I missed gregg's comment>>>
Manu Sporny:  if we're in a case where Apache and Express don't
   follow the spec, then there is a bigger disconnect.
Gregg Kellogg: question is, can a server respond with any time,
   even if it doesn't match what's in the ACCEPT header.
Gregg Kellogg: … This includes type parameters, needs research.
Manu Sporny:
   http://lists.w3.org/Archives/Public/public-rdf-comments/2013May/0038.html
Manu Sporny:  if the above satisfies Peter's comments then we
   should use that.
Niklas Lindström:
   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Niklas Lindström:  it sounds like we're restating the rules of
   content negotiiation
Stian Soiland-Reyes: I don't think you need to do 406 if it's
   just the profile parameter that can't be satisfied (it might be
   satisfied, the server just don't know that)
Manu Sporny:  we need to make sure we're not duplicating spec
   text

-- 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, 14 May 2013 15:50:22 UTC