JSON-LD Telecon Minutes for 2013-01-15

Thanks to François for scribing! The minutes from today's telecon are
now available.

http://json-ld.org/minutes/2013-01-15/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2013-01-15

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jan/0020.html
Topics:
   1. ISSUE-204: Compact @id's to relative IRIs
   2. ISSUE-205: Use the term URL instead of IRI in the (API)
      spec
   3. Approach to Algorithms
Resolutions:
   1. Add an at-risk issue on compacting IRIs as relative.
   2. Use IRI in the JSON-LD specifications instead of URL.
Chair:
   Manu Sporny
Scribe:
   François Daoust
Present:
   François Daoust, Manu Sporny, Niklas Lindström, Markus Lanthaler,
   Gregg Kellogg, David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-01-15/audio.ogg

François Daoust is scribing.
Manu Sporny:  Two additions to the agenda: IRI vs. URL, and
   relative compaction of URLs.
Niklas Lindström:  In the Royal Swedish National Library, where
   I'll be working starting in April, using JSON a lot, still some
   work to do to push forward on using RDF. Expect to be using
   JSON-LD explicitly and leverage the fact that JSON-LD can store
   non-mapped things, so this is good news for JSON-LD adoption.
Manu Sporny:  Is that public information?
Niklas Lindström:  Yes, it's a project on github, people will see
   it when we start integrating JSON-LD.

Topic: ISSUE-204: Compact @id's to relative IRIs

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/204
Manu Sporny:  We did some implementation over the week-end. We do
   a lot of digital signature work. We end up storing that info in a
   MongoDB database. When you compact to a relative IRI, you end up
   losing the base, which is bad when you need to check the digital
   signature again.
   … Now it seems that we need to store the base somewhere (which
   could be bad for some that only store the JSON-LD document...
   because - where are you going to put the base?), or change the
   parameters so that the compaction does not create relative IRIs.
   … I raise this as a concern. In some cases, it's a nice
   feature, but in other cases, it may destroy stuff such as digital
   signatures.
   … Not a big issue, but a bit too aggressive for our use cases.
   … In our systems, we do not want relative URLs, but I
   understand others may have different views.
Niklas Lindström:  I sympathize with this concern.
   … I didn't really have time to check the API, but I see the
   risk that someone might forget about that.
Markus Lanthaler:  Normally, you'd set the base IRI as an option
   in the JSONLD document... it defaults to the document IRI -
   depends on how you pass the document into the API. [scribe assist
   by Manu Sporny]
Markus Lanthaler:  If you don't do anything, there is text here
   that says it depends on the document IRI, but that depends on how
   you pass that IRI.
   … We may change things to pass the IRI explicitly and that
   would solve the problem
Manu Sporny:  The idea that this might happen in production is
   close to non existent
   … I don't know if we really need to do anything here. I'm
   leaning towards not doing anything.
Gregg Kellogg:  Usually, to serialize, you need to pass a base in
   order to resolve relative IRIs.
   … Every other RDF serialization allows me to output a
   statement of what the base is.
   … The reason we rejected that in JSON-LD is that we thought
   you could do that with a term.
   … If we had a way to automatically define a term that would be
   the base of the document, we'd solve the problem.
   … But then there is value in using compact IRIs.
Manu Sporny:  It sounds that there isn't a strong push towards
   changing current state of affairs.
Niklas Lindström:  what happens when you issue a compact call
   where the input is a compact JSON-LD with relative IRIs?
   … You'd need to pass the base URI and have no way to prevent
   that base IRI to be used in the output to generate new relative
   IRIs.
Gregg Kellogg:  [audio chopped]. I think you would get the result
   you wanted.
   … There is a danger of losing the base of the document.
Manu Sporny:  bottom line is that there are lots of ways to work
   around these use cases, we're just optimizing for the "main" use
   case. We have to realize that we could be wrong about that main
   use case, that's it.
Niklas Lindström:  Just recall something I saw on Twitter.
   General preferences in JSON APIs for relative IRIs? Responses
   were advocating in favor of absolute IRIs. You wanted to make
   things as simple as possible for consumers to follow links and
   resolving links is a (small) burden in the way of following
   links.
Niklas Lindström:  data consumption is easier if you use absolute
   IRIs consistently.
Manu Sporny:  That's the only thing that makes me hesitant about
   this feature.
Markus Lanthaler:  You generally want relative IRIs when you're
   debugging and do not want the base IRI of your staging/prod
   environment to bother you.
Manu Sporny:  I disagree, but I think we'll just go back and
   forth on that if we go on.

PROPOSAL: Add an at-risk issue on compacting IRIs as relative.

Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1 adding that I'd prefer an option for
   generating relative IRIs (defaulting to false), "debug mode"
   should not be the default
François Daoust: +1 to using at-rist for that.
Markus Lanthaler: +1
David I. Lehn: +0

RESOLUTION: Add an at-risk issue on compacting IRIs as relative.

Manu Sporny:  I think that's all we can do at this point.

Topic: ISSUE-205: Use the term URL instead of IRI in the (API) spec

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/205
Manu Sporny:  I spoke with a few folks in the WHATWG shortly
   before the call.
   … Markus proposed to close the issue by using the term URL.
   Pat Hayes and Conal reacted against that, I expect others in the
   RDF WG to follow.
   … I do not think we can convince them that using URL for the
   sake of Web developers is going to work because it's not
   "correct" in the strictest sense.
Niklas Lindström: .. example of IRI used in non-RDF-contexts:
   http://tools.ietf.org/html/rfc5988
Niklas Lindström: .. (Web Linking by Mark Nottingham)
Gregg Kellogg:  greater danger is that using url is trying to
   serve two masters.
Manu Sporny: There is this - http://url.spec.whatwg.org/
Manu Sporny:  the work on that is ongoing, the general feeling is
   that terminology will converge around "URL".
   … If we're looking towards the future, we'll see "urls", not
   "iris".
Gregg Kellogg:  If URLs and IRIs are unified, then good,
   otherwise it looks like a political stand that we do not need to
   take.
Markus Lanthaler: There's still an open issue for HTML5's URL:
   http://www.w3.org/html/wg/tracker/issues/56
Manu Sporny:  We want the spec to be for Web developers. They
   don't understand the distinction between URLs and IRIs. We should
   use terminology that Web developers are used to because that's
   our primary audience for this spec.
Gregg Kellogg:  Is this an argument to be brought to the RDF WG
   to ask them to update on-going specs to use URLs. If you cannot
   convince the group to do that, then you should not take a
   different route for JSON-LD.
Manu Sporny:  Rules are different for JSON-LD, the target
   audience is different for JSON-LD.
Gregg Kellogg:  I know you've been pushing against this, but the
   most proper place to use URLs would be in a JSON-LD primer,
   directly targeted at developers.
Gregg Kellogg: Just raised concerns about creating an arbitrary
   terminology difference with other RDF specs, which use IRI.
Gregg Kellogg: Serving two masters is never satisfying.
Niklas Lindström:  I agree with Gregg. IRI is the right term to
   use right now. I think I prefer a note saying that IRI is likely
   to become equivalent to URL in the future.
Manu Sporny:  I disagree, I think using IRI misses the point, but
   I'm feeling that I'm in the minority here. We're not creating
   JSON-LD to align ourselves with RDF (at least, I'm not), we're
   doing it to provide a technology for expressing Linked Data that
   is easy for Web Developers to use. If we use the IRI terminology,
   then we're not using terminology that is familiar to our primary
   audience... especially if that terminology (IRI) is going to be
   replaced in the future with "URL".
Niklas Lindström:  I would prefer to see URI actually but…
   anyway.
Manu Sporny:  So the argument that is being made by you guys is
   this: If the merger between URL and IRI had already happened, we
   would use URL. Since that's not there in REC form, it's going to
   be difficult to convince the RDF WG to go away from IRI for the
   rest of their specs. If we can't convince the RDF WG to go away
   from IRI based on a more recent REC, since JSON-LD is under the
   purview of that group, we cannot do the change in JSON-LD.
   … Note that we've taken a stand on this sort of stuff before,
   first with the push to use JSON-LD as the JSON representation of
   RDF that the group works on, and then with named graphs. We have
   JSON-LD and named graphs because we pushed for these sorts of
   things.
Gregg Kellogg:  A bit different because named graphs were already
   in the RDF Concepts.
   … I expect many battles in the future about IRI vs. URL
   … I agree with Niklas that the invention of the term IRI is a
   bit of a pity, URI is much better.
   … The URL stand is coming from people involved with Web
   browsers, so it's not surprising. Anne's document is not a spec,
   more of an opinion.
Manu Sporny:  It's an opinion that I happen to agree with
   strongly.
François Daoust:  This doesn't seem like it is an easy change -
   easy resolution is to use IRI in the end and not URL, let's stick
   to that. [scribe assist by Manu Sporny]

PROPOSAL: Use IRI in the JSON-LD specifications instead of URL.

Gregg Kellogg: +1
Manu Sporny: -1
François Daoust: +0
Niklas Lindström: +1
Markus Lanthaler: +0.5 (don't like the term but it's currently
   the most correct one)

RESOLUTION: Use IRI in the JSON-LD specifications instead of URL.

Topic: Approach to Algorithms

Manu Sporny: http://json-ld.org/spec/latest/json-ld-api/
Manu Sporny:  Markus went through and re-wrote the algorithms.
Manu Sporny:
   http://json-ld.org/spec/latest/json-ld-api/alternate.html
   … Gregg also went in to try to make the algorithms more
   descriptive than prescriptive. The discussion is to decide what
   should end up in the spec.
   … Any updates to these algorithms? Quick overview?
Gregg Kellogg:  I made use of Markus' work throughout my updates.
   I just updated it to remove the repetitive normative text. The
   biggest difference is sticking a bit closer to the original
   algorithms to try not to describe data structures that are useful
   in an implementation.
   … Other than IRI compaction, I think the algorithms are very
   similar
Markus Lanthaler:  Gregg uses term ranking algorithm, whereas I
   use inverse context.
   … Mine has complete fallback rules.
   … It's trivial to understand which term gets selected if you
   read the algorithms.
Gregg Kellogg:  We could replace the numbers in term rank with
   something else if needed.
Markus Lanthaler:  In the one case, you calculate numbers, in the
   other case, you look at containers. Hard to compare algorithms.
   In the end, it boils down to how you describe it.
Niklas Lindström:  Did not have time to sit down and read through
   this, and even less time to implement that. In general, I think
   that descriptive is better than prescriptive, as the spec is
   intended for humans.
   … My gut feeling is that I would probably do something akin to
   the inverse context.
   … When I read the ranking algorithm, I had trouble
   understanding it.
   … But I cannot really make an informed statement as to which
   is the better.
Manu Sporny:  Dave Longley had some time to read both of them. I
   find both of them moderately confusing, but term ranking a bit
   less so. I don't know how the rank gets computed but I understand
   how it works. With inverse context, it takes more place in the
   spec and feels more complex.
Markus Lanthaler:  What do you mean by "it takes up so much
   space"?
Manu Sporny:  You have to read a lot more to get the basic data
   in. With term rank, it's a bunch of "if" statements.
Markus Lanthaler:  you just start from step 1 and go through
   steps.
Gregg Kellogg:  another thing to consider is locality. We could
   redefine term ranking to be less math, but we rely on it for IRI
   compaction.
Niklas Lindström: +1 to make term ranking algorithm more about
   intent (less "number-oriented")
Manu Sporny:  In the end, the alternative document looks clearer.
   Dave Longley read some parts of both documents and and decided to
   implement things his own way.
Gregg Kellogg:  That's a very sensitive thing to do. If Dave have
   clearer algorithms, it would be good to know.
Manu Sporny:  The optimizations that Dave Longley is doing are
   because of benchmarking we're running on our servers. We found
   out that having to copy the context was very time consuming.
   … Many of these optimizations should not go in the spec
   because they are just too complex.
Gregg Kellogg:  Instead of saying "copy context", we should
   simply say "use the context".
Manu Sporny:  I think we already do that in the spec.
   … It's simpler to say "make a copy" as people understand they
   can modify the copy without breaking the original, but
   implementers can optimize there.
   … Other parts of the algorithms that changed dramatically?
Gregg Kellogg:  I haven't looked at "flatten". My updates were
   made to come to an agreement with Markus.
Manu Sporny:  I think the result is a nice consensus between both
   views.
Niklas Lindström:  we could make it clear in the spec that the
   algorithms are very descriptive since we already know that they
   are suboptimal.
   … I'm convinced my way is not the fastest. Something to that
   effect in the spec would be good.
Gregg Kellogg:  Yes. Putting implementation notes is a reasonable
   thing to do, either inline or as an appendix.
Manu Sporny:  two things that we need to decide here. General
   approach and what bugs need to be fixed.
François Daoust:  I found a number of bugs by just quickly
   skimming over it. I know that the spec that I wrote almost
   exactly matches my code. [scribe assist by Manu Sporny]
Gregg Kellogg:  For the most part, this is what I implement.
   [scribe assist by Manu Sporny]
Gregg Kellogg:  if there are bugs, we need to focus on those.
   [scribe assist by Manu Sporny]
Manu Sporny:  I'm very concerned about holding up the work
   waiting for a complete implementation of all algorithms. [scribe
   assist by Manu Sporny]
Markus Lanthaler:  Then what's the point of a test suite if all
   of the algorithms haven't been impelemnted verbatim at least
   once? [scribe assist by Manu Sporny]
Manu Sporny:  The reason test suites exist is to ensure that
   implementations match the algorithms. The test suite doesn't
   exist to ensure that everybody implements the algorithms exactly
   as they are laid out in the spec. In fact, this almost never
   happens - everybody has their own twist on implementing the
   algorithms. With enough eyes on those algorithms, we'll get the
   right over the next few months. We're talking about minor bugs,
   not major design issues. I don't think we should hold up going to
   Last Call until we have a verbatim implementation of all
   algorithms. [scribe assist by Manu Sporny]
Markus Lanthaler:  I disagree, I don't buy that argument. I think
   we need to make sure that somebody has implemented the algorithms
   verbatim, that way we'll know if they're correct. [scribe assist
   by Manu Sporny]
Manu Sporny:  That rarely happens when working on these specs.
   Typically, a few editors write the algorithms, verify that the
   intent is correct, then each may go off an do their own
   implementation. These algorithms are meant to be descriptive, not
   something somebody can take an implement verbatim (even though
   that is how you rewrote the algorithms. [scribe assist by Manu
   Sporny]
Manu Sporny:  It doesn't look like we're going to get agreement
   on this topic this week.  [scribe assist by Manu Sporny]
Manu Sporny:  I'll have Dave Longley send thoughts on to the
   mailing-list. Let's continue discussion on this topic next week.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Tuesday, 15 January 2013 17:28:00 UTC