JSON-LD Telecon Minutes for 2013-06-04

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

http://json-ld.org/minutes/2013-06-04/

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

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-06-04

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jun/0005.html
Topics:
   1. Vikash's Summer of Code
   2. RDF-ISSUE-133: Reverse properties
   3. RDF-ISSUE-134: Blank node labeling
   4. RDF-ISSUE-129: Lossless conversion
   5. The Candidate Recommendation Phase
   6. Other concerns and news
Resolutions:
   1. Support reverse properties in JSON-LD 1.0.
   2. The default value of the useNativeTypes flag should be set
      to 'false' in the JSON-LD API.
   3. Add explanatory text to the JSON-LD API specification
      explaining the risks of the useNativeTypes flag and how to do
      proper conversion to/from native types using the to/from RDF
      method call.
Chair:
   Manu Sporny
Scribe:
   Markus Lanthaler
Present:
   Markus Lanthaler, Manu Sporny, Vikash Agrawal, Paul Kuykendall,
   Gregg Kellogg, Niklas Lindström, Dave Longley,
   Stian Soiland-Reyes, Sandro Hawke, Clay Wells, Kuno Woudt
Audio:
   http://json-ld.org/minutes/2013-06-04/audio.ogg

Markus Lanthaler is scribing.

Topic: Vikash's Summer of Code

Manu Sporny:  Vikash, could you outline your plan for the summer
   & what you need from the group
Vikash Agrawal:  I'm starting with the redesign of the page
   ... there are some problems with IE
Dave Longley: http://www.modern.ie/en-us
Dave Longley: https://github.com/json-ld/json-ld.org/issues/242
   ... next I'll create the schema.org data generator (form to
   enter data which is converted to json-ld)
   ... shouldn't take much time
Manu Sporny:  do you need any help?
Vikash Agrawal:  how do I push?
Manu Sporny:  we'll start of with pull requests
   ... someone with commit access will merge them in a timely
   manner
   ... and then the changes will go live immediately
Vikash Agrawal: Two pull requests for -
   http://dl.dropboxusercontent.com/u/5278881/GSoC/json-ld/index2.html
Vikash Agrawal:

https://dl.dropboxusercontent.com/u/5278881/GSoC/json-ld/playground/index2.html
Vikash Agrawal: https://github.com/json-ld/json-ld.org/issues/242
Paul Kuykendall:  how should comments be made?
Manu Sporny:  best is to use GitHub... just raise issues. We'll
   assign them to Vikash.

Topic: RDF-ISSUE-133: Reverse properties

Manu Sporny: http://www.w3.org/2011/rdf-wg/track/issues/133
   ... We more or less came to an agreement that we'll keep
   support for reverse properties
   ... we got feedback from people that it is an important
   feature for them
   ... no requests to take it out
Gregg Kellogg:  this is a very useful feature as danbri showed on
   the mailing list
Gregg Kellogg: https://gist.github.com/gkellogg/5691913
Dave Longley:
   http://lists.w3.org/Archives/Public/public-linked-json/2013May/0093.html
Manu Sporny:  looking for that email? [scribe assist by Dave
   Longley]

PROPOSAL: Support reverse properties in JSON-LD 1.0.

Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Dave Longley: +1
Gregg Kellogg: +1
Stian Soiland-Reyes: +1
Paul Kuykendall: +1
Vikash Agrawal: +1

RESOLUTION: Support reverse properties in JSON-LD 1.0.

Topic: RDF-ISSUE-134: Blank node labeling

Manu Sporny: http://www.w3.org/2011/rdf-wg/track/issues/134
Markus Lanthaler:  the discussion about this restarted in the RDF
   WG
Manu Sporny:  our position didn't change
Gregg Kellogg:  there's a meta-discussion about how to deal with
   bnode predicates
   ... do we need a flag in toRDF algorithm to only produce valid
   triples
Manu Sporny:  someone on Twitter mapped GeoJSON to JSON-LD
   ... most predicates are mapped to bnodes
   ... this is a nice use-case
Markus Lanthaler:  here's the tweet:
   https://twitter.com/sgillies/status/341612872683622400
Markus Lanthaler:  and the JSON file:
   http://pleiades.stoa.org/places/628932/json
Gregg Kellogg:  nevertheless a flag to control whether only
   standardized RDF is outputed would be helpful
Paul Kuykendall:  absolutely
Gregg Kellogg:  the problem with skolemization is that it happens
   by using the server's address which might be problematic in some
   cases
Sandro Hawke:  I think it is fine to skolemize with a fixed URL
   e.g. w3.org
Markus Lanthaler:  Since we just specify it quite generically,
   isn't this something that has to be done at a layer above the
   algorithm? [scribe assist by Manu Sporny]
Gregg Kellogg:  good point. [scribe assist by Manu Sporny]
Manu Sporny:  Yes. This is also true for things that have to do
   with normalization etc.
Gregg Kellogg:  Agreed, but we should probably add a note

PROPOSAL: Add a note to the toRDF() algorithm warning developers
   that blank node predicates and graph labels will have to be
   translated before the toRDF() algorithm is run in order to ensure
   compatability with RDF Concepts 1.1.

Markus Lanthaler:  We currently have this in the spec:
"This algorithms converts a JSON-LD document to an RDF dataset.
   Please note that RDF does not allow a blank node to be used as a
   graph name or property, while JSON-LD does. JSON-LD-RDF
   Converters can work around this restriction, when converting
   JSON-LD to RDF, by converting such blank nodes to IRIs, minting
   new "Skolem IRIs" as per Replacing Blank Nodes with IRIs of
   [RDF11-CONCEPTS]."
Dave Longley:  we may wanna use "may" instead
Manu Sporny:  I think what Markus just put in IRC is enough
Sandro Hawke:  ok, I would be fine with that
   ... if you have some arguments please join the discussion in
   the RDF WG
Manu Sporny:  I have problems seeing us making the same points
   over and over again
   ... we made our arguments quite clear I think
   ... no convincing technical argument against it has been
   raised so far
   ... So Sandro, I don't know what you want us to say. I feel
   like we are repeating ourselves
Sandro Hawke:  maybe some people didn't see the points you made
   before so repeating them might help
Manu Sporny:  I just find it slightly frustrating
Sandro Hawke:  are you guys willing give up bnode predicates if
   you get bnode graph labels
Manu Sporny:  seems like negotiation which is dangerous if there
   are technical arguments for features
   ... the outcome should not be based on politics

Topic: RDF-ISSUE-129: Lossless conversion

Manu Sporny: http://www.w3.org/2011/rdf-wg/track/issues/129
Markus Lanthaler:  The discussion here is around two positions -
   1) move conversion from fromRDF to compaction/expansion, 2) keep
   it in to/from RDF conversion algorithm. [scribe assist by Manu
   Sporny]
Markus Lanthaler:  We don't need to add complexity to JSON-LD
   processors. [scribe assist by Manu Sporny]
Markus Lanthaler:  We also need to outline how this works in
   detail... xsd:integer vs. xsd:double, there are details we need
   to work out. All integers are floats in JavaScript... in certain
   cases, such as a xsd:double, it would become an integer. [scribe
   assist by Manu Sporny]
Gregg Kellogg:  There is another argument, if it's done as part
   of compaction, it could make use of typecasting as a part of a
   property to get the appropriate format. [scribe assist by Manu
   Sporny]
Markus Lanthaler:  Type coercion only applies to strings, it
   doesn't apply to numbers of booleans. [scribe assist by Manu
   Sporny]
Sandro Hawke:  If it was a string, type conversion could convert
   it to a number - it could be converted into a JSON Number.
   [scribe assist by Manu Sporny]
Markus Lanthaler:  Are we talking about literal to native types.
   [scribe assist by Manu Sporny]
Gregg Kellogg:  Native types don't matter, you could easily do
   that in RDF transformation phase... it could be integer, double,
   etc. The problem is the other way arond - going from a number to
   a stirng. [scribe assist by Manu Sporny]
Gregg Kellogg:  In order to get appropriate output form. if you
   had xsd:decimal, and a string "0.2323" - then transformation
   could generate xsd:decimal in output. [scribe assist by Manu
   Sporny]
Markus Lanthaler:  Yes, but that would change our algorithms
   quite dramatically. Type coercion/language tagging is only used
   if it's a string. [scribe assist by Manu Sporny]
Sandro Hawke: +1 move conversion to expansion/compaction, +1
   convert all numeric types to Number
Sandro Hawke:  I haven't used the JSON-LD API
   ... but my feeling is you want that in expansion/compaction
Sandro Hawke:  I had not used the JSON-LD API ever, so I don't
   have a lot of weight. My feeling is that you'd want this in
   expansion/compaction. Even if I'm not going anywhere near RDF, if
   I get some JSOn-LD from across the net, and my code just wants to
   deal w/ numbers, it might come in with xsd types on numeric
   things. I'd want to be able to convert those to numbers. [scribe
   assist by Manu Sporny]
Sandro Hawke:  the other way I would expect all numbers to go to
   just xsd:double
Sandro Hawke:  I'd also want something going the other way too, I
   think. I'd expect all numbers to go to double. Anything else is
   going to be fuzzy. It's going to be lossy, whatever you do.
   [scribe assist by Manu Sporny]
Sandro Hawke:  Unless you have more type information. [scribe
   assist by Manu Sporny]
Sandro Hawke:  One more argument for putting it in
   expansion/compaction - I want to dissuade people doing this when
   they convert to RDF. I think it's bad to do this before sending
   this to some place unknown. [scribe assist by Manu Sporny]
Dave Longley:  what we want here is probably something more
   fine-grained
   ... you might want to be able to convert just certain things
   based on your context
Dave Longley: compaction option? convertToNativeNumbers:
   ['xsd:integer', 'foo:bar']
   ... so we might wanna do it in expansion and compaction
Sandro Hawke: How about another routine? NativizeNumbers
Stian Soiland-Reyes: you can't put all as xsd:double -
   9223372036854775807 (max of xsd:long) would become
   9223372036854775808 after a trip through xsd:double
   ... only type-coerced properties would be converted to native
   types then
Niklas Lindström:  I don't have strong opinions here
   ... I think putting it in both places makes sense
   ... and it also makes sense to be able to control what to
   convert (e.g. just integers)
Sandro Hawke: Grrrrr. Can't connect via VOIP or Telco. Telco gets
   me a fast busy. VOIP call times out.
   ... if you get JSON-LD you might wanna re-compact it to get
   native types
Markus Lanthaler:  What Dave said certainly makes sense
   ... but I think that could be done as a proprietary extension
   to JSON-LD processors
   ... do we really need to standardize this?
   ... This would probably mean that we need through another LC
Gregg Kellogg:  I liked Markus proposal to go through RDF
   conversion to convert literals to native types
   ... you loose the structure of the document but the use case
   here is really for data coming from RDF so it shouldn't matter
   much in practice
Dave Longley:  The downside of this is that there isn't any
   fine-grainded control
   ... you could potentially loose data
Gregg Kellogg:  yeah, but we dealt with this issue for such a
   long time and this is what we decided to do
   ... there's not really new information suggesting that we need
   to change it
   ... I think following a minimalistic approach is the way to go
   here
Manu Sporny:  the initial concern was raised by Sandro
   ... it was about data fidelity
   ... in that case just don't convert to native types
   ... if we change the default value so that there's no data
   loss that concern should be addressed
   ... of course there are other options with some advantages but
   they make the algorithms more complex and probably mean another
   LC
   ... so, if we would change the default value of useNativeTypes
   would that address your concerns Sandro?
Sandro Hawke:  it is not my desired outcome but I could live with
   it. Also just adding a note making it clear to not send native
   types over the wire may work
Manu Sporny:  this buys us time to gain experience how this will
   be used
   ... otherwise we might risk introducing other issues in the
   last minute
Gregg Kellogg:  but that doesn't give developers a tool which
   don't care about RDF to convert literals to native types now
Dave Longley:  I think what Manu says is that we extend it in the
   future
Dave Longley: s/dave/sandro
Gregg Kellogg:  we should at least add a note explaining that RDF
   roundtripping can be used for this
   ... I also liked Markus proposal about adding a function
   wrapping that round-tripping in a simple call
Manu Sporny:  So the proposal is to change the default value of
   useNativeTypes to false and add a note explaining the use of RDF
   round-tripping

PROPOSAL: The default value of the useNativeTypes flag should be
   set to 'false' in the JSON-LD API.

Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
Clay Wells: +1
Markus Lanthaler: +1
Stian Soiland-Reyes: +1
Niklas Lindström: +1
Sandro Hawke: +1
Vikash Agrawal: +1 (take one from me)

RESOLUTION: The default value of the useNativeTypes flag should
   be set to 'false' in the JSON-LD API.

PROPOSAL: Add explanatory text to the JSON-LD API specification
   explaining the risks of the useNativeTypes flag and how to do
   proper conversion to/from native types using the to/from RDF
   method call.

Markus Lanthaler:  We could add it to the data round-tripping
   section. [scribe assist by Manu Sporny]
Gregg Kellogg: +1
Dave Longley: +1
Manu Sporny: +1
Vikash Agrawal: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Stian Soiland-Reyes: +1
Clay Wells: +1

RESOLUTION: Add explanatory text to the JSON-LD API specification
   explaining the risks of the useNativeTypes flag and how to do
   proper conversion to/from native types using the to/from RDF
   method call.

Topic: The Candidate Recommendation Phase

Markus Lanthaler:  When are we going to CR? [scribe assist by
   Manu Sporny]
Manu Sporny:  We need to do some updates to the spec, maybe in
   2-3 weeks. [scribe assist by Manu Sporny]
Gregg Kellogg:  we also need to stabilize the test suite
Dave Longley:  we didn't talk about the other XSD data types
   ... we currently just support xsd:double and xsd:integer
   ... what about the other numeric types
Markus Lanthaler:  that was something that Pierre-Antoine (or
   Sandro, can't remember) proposed

Topic: Other concerns and news

Manu Sporny: Currenty, fromRDF creates nodes for things that are
   only in the object position.
Manu Sporny: We may want to discuss support for xsd:short and
   other integer types.
Manu Sporny: We should also discuss issue 253
Vikash Agrawal: manu-db, I just have one question as I wanted to
   know how Google is using JSON-LD in GMail?
Manu Sporny: vikash, here you go:
   http://manu.sporny.org/2013/gmail-json-ld/
Manu Sporny: and here
   http://manu.sporny.org/2013/json-ld-google-search/
Vikash Agrawal: thanks :)
Niklas Lindström: .. just a note: I held a quick lightning talk
   last week on JSON-LD at ELAG 2013. Slides here:

http://www.slideshare.net/niklal/something-specificandsimpleniklaslelag2013
Niklas Lindström:  I saw people talking about JSON-LD at
   #elag2013 and wondered: "How in the hell did they hear about
   it?!" :P [scribe assist by Manu Sporny]
Manu Sporny: now I know.
Niklas Lindström:  saw a number of very nice comments from the
   audience during your talk.. lots of "ooh, JSON-LD, gonna have to
   check it out" [scribe assist by Manu Sporny]
Manu Sporny:  :) I think the first mention was from Herbert van
   de Sompel in the keynote though; and it was mentioned in some
   other talks as well. Which was really nice (and prompted me to
   talk about it). [scribe assist by Niklas Lindström]
Niklas Lindström:  Did you plan to talk about it? Or did you just
   decide while you were there? [scribe assist by Manu Sporny]
Manu Sporny:  while I was there. I wrote up the title before I'd
   decided on the topic. ;) [scribe assist by Niklas Lindström]
Niklas Lindström: .. needed to assess what the crowd was
   interested in. JSON-LD is quite great for library data, which is
   internally rather minutely detailed and "feels local", but has to
   be mashable and coordinated with the "wilder" web.
Niklas Lindström:  it's a really good slide deck - concise, cuts
   right to the point. [scribe assist by Manu Sporny]
Manu Sporny:  thanks! I aimed to make it true to the title. ;)
   [scribe assist by Niklas Lindström]
Manu Sporny: For those that didn't see it yet, schema.org just
   announced that they're adding JSON-LD as an official format:
   http://blog.schema.org/2013/06/schemaorg-and-json-ld.html
Kuno Woudt: nice!
Niklas Lindström: Nice indeed!

-- 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 Thursday, 6 June 2013 20:56:04 UTC