W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2012

JSON-LD Telecon Minutes for 2012-06-19

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 19 Jun 2012 11:29:23 -0400
Message-ID: <4FE09AD3.5030200@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
bcc: RDF WG

Thanks to François for scribing! The minutes from today's call are now
available here:


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

JSON-LD Community Group Telecon Minutes for 2012-06-19

   1. Feedback from RDF WG
   2. Linked Data and JSON-LD introductory videos
   3. ISSUE-26: @vocab support
   4. ISSUE-129: Eliminate duplicates in expansion
   5. ISSUE-108: IRI templates
   1. Support the @vocab keyword for setting a default vocabulary
      URL for a JSON-LD document.
   2. Remove text relating to removing duplicates when expanding
      JSON-LD documents
   3. Do not add any normative language relating to IRI templates
      or other transformations
   Manu Sporny
   François Daoust
   François Daoust, Manu Sporny, Gregg Kellogg, Niklas Lindström,
   Markus Lanthaler, David I. Lehn, Dave Longley

François Daoust is scribing.
Manu Sporny:  Agenda on IRC. Anything else to add?
Gregg Kellogg:  do we want to talk about feedback we got?

Topic: Feedback from RDF WG

Manu Sporny:  We have two reviews in. A full one and a partial
   one from EricP
   … I read through seaborne's review
   … There are some last call blockers in there. Gregg, do you
   want to take them one by one or high level overview?
Manu Sporny: Andy Seaborne's review:
Gregg Kellogg:  High level. There's a related thread on
   eliminating graphs and using @id-maps instead
Manu Sporny: Eric Prud'hommeaux's review:
   … I think that the point is to put things at risk. Graph has
   not been entirely embraced by the RDF WG. The notion of named
   graph is not a closed issue.
Gregg Kellogg:  the reason that we have put graphs in there. If
   you have a bunch of objects in an array form, you need some way
   to put them in a graph. If you have IDs, you wouldn't need
Manu Sporny:  I'm still confused as to how you name the graph.
Gregg Kellogg:  let me type something
Gregg Kellogg: {@context:{}, @graph:[{@id: a}, {@id: b}]}
Gregg Kellogg:  that's what you might have.
Gregg Kellogg: a: {@id:a, @container: @id}
   … If you have @id-map, you can instead have:
Gregg Kellogg: {@context: {}, a: {@id: a}, b: {@id: b}}
Gregg Kellogg:  'a' is a subject ID, and then it references the
   subject definition. There is no graph.
   … It would allow us to put subjects that are URIs as keys.
   … This is not for the named graph case.
Manu Sporny:  So there are two problems: how do we name a graph,
   and how do we use subject identifiers as keys.
Gregg Kellogg:  the original use of graph was not to name graph,
   it was just as a way to have multiple objects
   … assuming we needed to remove the concept of named graph from
   JSON-LD, this could be a solution
Manu Sporny:  I don't know if we need to discuss a solution for
   if we have to remove named graph from JSON-LD.
   … That seems to be food for last call comments. The RDF WG
   needs to figure that out.
   … It's so fundamental to real case uses that I don't want to
   remove it right away unless necessary.
Gregg Kellogg:  there was a threat that it might need to be
   removed. If it is at risk, then we'd better have counter
Manu Sporny:  Ivan even said that he was using language a bit too
   strong. It's perfectly fine to have things in there that might
   become at risk in the future.
   … Marking them at risk now sends the wrong message, I think.
Niklas Lindström:  named graph is much more complex than a
   document format for triples. We could use @set instead of @graph
   if we want to avoid using @graph.
Markus Lanthaler: timezone confusion.. thought it's in an hour
Manu Sporny:  The concern I have is that if we reopen the
   discussion, it will mean spending multiple weeks on this whereas
   we already have a solution.
   … I'd rather have them come up with a strong case about why we
   need to drop that from JSON-LD
   … Any other strong opinion on this?
Niklas Lindström:  My feeling is that named graph hasn't been
   needed in e.g. Turtle.
Manu Sporny:  I disagree.
   … In our case, there's no name graph support in RDFa, so we
   end up with all this soup that's more complicated. We have
   different ways to generate IDs for the graphs and so on.
   … I disagree with the notion that we haven't been needing
   named graph in RDF/XML, Turtle and so on.
Niklas Lindström:  I see your point. You have a very good solid
   use case. Discussions about named graph are much more esoteric.
   … This use case about signature is much more about packaging
   and transportation of data.
Manu Sporny:  that's precisely my point. I'd like a list of
   concrete use cases that we need to solve, to think about
   solutions that are easy to use for developers.
   … We're coming from the other direction: "this is what we
Niklas Lindström:  I think it's important to highlight this. This
   can be aligned with existing things in SPARQL.
Manu Sporny:  Important thing to discuss is how we're going to
   address feedback from the RDF WG. First thing is to get a feeling
   tomorrow on whether we need to make further changes to JSON-LD.
   … We could perhaps hand the document over to RDF WG, making
   necessary patent commitments, publish the FPWD and then move on
   from there in the RDF WG.
   … Maybe the best way forward is to ask Andy and Eric what
   precise changes they want to see.
Gregg Kellogg:  they both stated that they didn't see any
   blockers to FPWD. That's my interpretation.
Manu Sporny:  right. Just getting confirmation on that would be
   … I've heard people say that before and then have issue with
   publication as FPWD.
Gregg Kellogg:  I suggest we make some of the purely editorial
   changes that are in there, and then sprikle some issue markers
   and be done with that.
Manu Sporny:  do you want to make a pass?
Gregg Kellogg:  yes.
Manu Sporny:  I'm asking because I don't think I'll have time
   this week.
Gregg Kellogg:  I think I can do a quick pass.
Manu Sporny:  Would you mind waiting up until after the call
   tomorrow to have a clearer view as to what changes might be
Gregg Kellogg:  what I really want is to put issue markers.
Manu Sporny:  ok. Anything else on this topic?

Topic: Linked Data and JSON-LD introductory videos

Gregg Kellogg: Good job on the videos!
Manu Sporny: What is Linked Data?
Manu Sporny:  I spent some time this week-end to put together two
   videos on Linked Data and JSON-LD.
Manu Sporny: What is JSON-LD?
   … Introduction to Linked Data and introduction on JSON-LD.
   … I would really appreciate feedback from you guys. Anything
   that could help improve the videos
   … If they look cheap, stuff to add/remove.
Gregg Kellogg:  I think they are great.
   … I don't have any technical feedback. I'll put that on my
   … It looks to me to be very approachable, so very valuable
Manu Sporny:  One of the things I need to do is to have a
   … Maybe translating would be good? Francois for instance if
   you have time?
   … Or maybe in Japanese.
   … We could put the transcript on github and then have people
   translate it.
François Daoust:  The video's are good - they just explain things
   pretty easily - I don't have time right now... I'm happy to try
   translating to French. Don't know when I could do it. [scribe
   assist by Manu Sporny]
François Daoust:  It would be valuable if you could extract the
   slides - could you do that? [scribe assist by Manu Sporny]
Manu Sporny:  OK, I'll try to extract the images. I don't have a
   scanner, though ;)
David I. Lehn: i can scan them at home for you
Manu Sporny: Thanks Dave Lehn... will take you up on that offer.
Niklas Lindström:  I just wanted to echo the previous feedback on
   the quality of the videos. Only had time to watch one.
Manu Sporny:  anything else on the videos before we move on?
Gregg Kellogg:  just good job!

Topic: ISSUE-26: @vocab support

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/26
Manu Sporny:  question about whether we should put @vocab back in
   the spec. This is only @vocab. I don't think anyone is trying to
   put @base back.
   … Almost everyone seems to be willing to bring @vocab back.
Dave Longley:  I think it would be ok to bring @vocab back in the
   spec. I'm not totally opposed to it.
Gregg Kellogg:  Markus raised some concerns. I don't know if he's
   totally on board.
   … To me, it's obvious. Whenever I play with people, @vocab is
   so useful because it allows to skip the "term" mapping for quick
Manu Sporny:  Question about @vocab from external JSON-LD

PROPOSAL:  Support the @vocab keyword for setting a default
   vocabulary URL for a JSON-LD document.

Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
Markus Lanthaler: -0
David I. Lehn: +0

RESOLUTION: Support the @vocab keyword for setting a default
   vocabulary URL for a JSON-LD document.

Manu Sporny:  Markus, could you outline your concerns?
Markus Lanthaler: can you hear me?
Markus Lanthaler: ok :-)
Markus Lanthaler: was already wondering before :-)
Dave Longley:
Markus Lanthaler: my thoughts are basically in the issue
Markus Lanthaler: it adds cognitive overhead: two base IRIs
Markus Lanthaler: issue with external contexts
Manu Sporny:  Markus says that developers were confused about
   having to use two base IRIs.
Markus Lanthaler: and the word @vocab itself is a bit confusing
   itself apparently
Markus Lanthaler: to what vocab applies.. @type and properties
   … I don't think that the main issue is about using prefixes. I
   just think many developers will just want to use "schema.org" and
   have JSON-LD documents that are prefix-less.
Markus Lanthaler: will call back in in a sec.. hope to solve
   audio issues
Dave Longley:  I think the confusion is more about how the future
   will work
Niklas Lindström:
Niklas Lindström:  I just want to reference the notion of
   (in-)transitivity of @vocab. That same notion should apply to

Topic: ISSUE-129: Eliminate duplicates in expansion

Manu Sporny:  ok, not a discussion for today.
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/129
Manu Sporny:  The question is whether or not we should remove
   duplicates automatically.
   … If we don't do duplicate elimination, there are follow-up
Gregg Kellogg:  In terms of toRDF, you can certainly specify
   duplicate values. There is nothing wrong in JSON-LD with having
   multiple values when you generate RDF. The same would happen in
   … The graph model would eliminate them on its own
Dave Longley:  It's probably the case that most people that will
   be using JSON-LD directly without going from/to RDF will be using
   some kind of duplicate eliminitation. I actually agree with
   Markus that we should remove duplicates to simplify.
   … The question is how to handle them in the normalization
   algorithm. At the end of it, we should leave duplicates around in
   expansion algorithm.
   … In my particular implementation I have a couple of methods.
   They are going to need to be different for the expansion
   algorithm. In other parts, you'll want to remove duplicates, but
   not for the expansion.
Dave Longley: no

PROPOSAL:  Remove text relating to removing duplicates when
   expanding JSON-LD documents

Gregg Kellogg: +1
Dave Longley: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
Manu Sporny: +1

RESOLUTION: Remove text relating to removing duplicates when
   expanding JSON-LD documents

Topic: ISSUE-108: IRI templates

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/108
Gregg Kellogg:  at some point translating legacy JSON into
   JSON-LD should be a note but for now it's outside of the scope of
   what we're trying to accomplish [scribe assist by Dave Longley]
Gregg Kellogg:  it's useful and will be common. [scribe assist by
   Dave Longley]
Markus Lanthaler:  i agree, we should close the issue and not
   address it directly in JSON-LD for now. [scribe assist by Dave

PROPOSAL:  Do not add any normative language relating to IRI
   templates or other transformations

Gregg Kellogg: +1
Dave Longley: +1
Markus Lanthaler: +1
Niklas Lindström: +0.75 (I've seen potential, but it's reasonably
   too complex)
David I. Lehn: +0
Manu Sporny: +1

RESOLUTION: Do not add any normative language relating to IRI
   templates or other transformations

Gregg Kellogg:  i think that's it for the issues today and given
   the audio problems we're having i suggest we end the call.
   [scribe assist by Dave Longley]
Gregg Kellogg:  any other issues? [scribe assist by Dave Longley]
Markus Lanthaler:  i wanted to ask about a decision made last
   time, but we can do that on the mailing list. [scribe assist by
   Dave Longley]
Gregg Kellogg:  i think it's pretty clear in the audio log what
   we were trying to accomplish, but if you raise an issue we can
   put it on the agenda next time. [scribe assist by Dave Longley]
Gregg Kellogg:  bye everyone [scribe assist by Dave Longley]

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
Received on Tuesday, 19 June 2012 15:30:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:05 UTC