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.
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: 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.
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.
… 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.