Manu Sporny: https://github.com/json-ld/json-ld.org/issues/217

Manu Sporny: A bit of a breakthrough in the RDF WG, which is great. We need to support BNodes identifier for graph names. I think that's all we need. We don't really need Pat Hayes suggestion, although it would be nice.

Niklas Lindström: Not comfortable if that deviates from what the RDF WG decides

Gregg Kellogg: I agree. I don't think that's the way to do it.

Manu Sporny: That's fine, I don't feel strongly about this being in the spec, but I do think strongly that it's the right thing to do.

Gregg Kellogg: My update to the RDF algorithms was to note that this is an issue. We could say that it is at risk.

Manu Sporny: Markus, Gregg, and myself, let's make sure we show up on tomorrow's RDF call then.

Manu Sporny: OK, then waiting for the RDF WG to come up with a resolution.

Gregg Kellogg: Yes, it would be useful

Niklas Lindström: maybe some informal recommendation that IRIs are preferred.

Gregg Kellogg: Not so sure. Eric came up with a few examples where BNodes identifier are the best way forward.

Markus Lanthaler: isn't it enough to say that we don't change our current spec?

Gregg Kellogg: the point of the proposal is to point to a decision of this group that strongly supports that position in order to get the concepts updated.

Gregg Kellogg: +1

Manu Sporny: +1

Dave Longley: +1

François Daoust: +1

Niklas Lindström: +1

Markus Lanthaler: +1

Manu Sporny: The only thing that was blocking the publication was that graph name thing.

Gregg Kellogg: I think we can publish it as an FCGS right now and have the RDF WG understand that one issue moving forward is the graph name discussion.

Manu Sporny: OK, so proposal is to publish the syntax spec as FCGS

Manu Sporny: +1

Markus Lanthaler: +1

Gregg Kellogg: +1

Dave Longley: +1

François Daoust: +1

Niklas Lindström: +1

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/218

Manu Sporny: Markus has done a fantastic job at getting all our comments as a checklist in the issue tracker.

Markus Lanthaler: basically the same as last week.

Dave Longley: I'm looking at the list. There are a couple of things where we're still trying to figure out if we want to reorganize algorithms.

Gregg Kellogg: My previous implementation folded the keywords aliasing into the normal term processing.

Manu Sporny: What might help is finding what things the editors need feedback about. One way is editors go ahead and discuss things among themselves. Or we go through the group for each and every point but that would be a disaster in terms of time.

Markus Lanthaler: difficult to isolate what really needs to be talked about.

Manu Sporny: If both of you disagree, we can escalate to the group.

Gregg Kellogg: It's worth spending time on this call going through the list.

Markus Lanthaler: I agree. I haven't made some changes not to have to revert the changes afterwards.

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/218#issuecomment-13449440

Manu Sporny: OK, let's start from the top, then

Manu Sporny: About "folksy wording", I agree.

Gregg Kellogg: agreement about this, it's just the work needs to be done.

Manu Sporny: It doesn't really need to be done for this version but the RDF WG will complain about it, for sure.

Gregg Kellogg: It's important to prioritize things that change the algorithms.

Manu Sporny: So feedback on first one is "make the changes when algorithms are updated".

Markus Lanthaler: note it also contains a note on relative IRIs.

Gregg Kellogg: I'll edit the note to move the first part to the end of the "folksy" comment and keep the later part.

Dave Longley: Maybe add "relative IRI" to terminology to explain how it gets resolved.

Manu Sporny: I like the idea to be more general about it and put it in the terminology.

Dave Longley: sort of micro-algorithms, that's one of these examples.

Markus Lanthaler: If the remote context includes another remote context, what base IRI to use? It's not that trivial.

Gregg Kellogg: The main case is when you resolve the remote context IRI which is relative.

Markus Lanthaler: We don't allow relative IRIs for terms in context

Gregg Kellogg: so maybe it's not an issue anymore.

Manu Sporny: we seem to be heading in the right direction for this one.

Manu Sporny: comment on "xxx equals null" to be replaced by "xxx is null".

Gregg Kellogg: It's an English usage. It just sounds unnecessary.

Dave Longley: I agree. I just wanted to be consistent. I prefer the shorter version.

Manu Sporny: ok, skipping down to "Otherwise is awkward". What is the alternative?

Gregg Kellogg: This was with respect to a statement that is perhaps not there anymore. I don't remember where it was.

Manu Sporny: ok, moving on to duplicate normative statments.

Gregg Kellogg: that echoed Markus feedback on my alternative version where I had duplicated these statements.

Dave Longley: I would prefer avoiding using these terms.

Manu Sporny: Are we skipping this for now?

Markus Lanthaler: I think we all agree that it shouldn't duplicate normative statements.

Manu Sporny: I'm not too worried about that if that makes writing the algorithms easier.

Manu Sporny: ok, moving on to last point in Gregg's list.

Dave Longley: I think he's talking about the features section, let's add a link to the API section there. [scribe assist by Manu Sporny]

Dave Longley: introduction should point to API as well. [scribe assist by Gregg Kellogg]

Manu Sporny: http://json-ld.org/test-suite/

Gregg Kellogg: the test suite is referenced generically. We could get an EARL report in place to link tests and the spec.

Gregg Kellogg: http://rdfa.info/earl-reports/

Gregg Kellogg: [going through the earl reports example]

Manu Sporny: I would not be opposed to do that.

Gregg Kellogg: I may volunteer to do a variation of the report that does the job for us.

Manu Sporny: this work needs to be done to get us out of CR.

Gregg Kellogg: Something actionable right now would be adding a note pointing user to the test suite to provide more examples.

Manu Sporny: Fine with that. [no objection heard]

Manu Sporny: Going through Markus' feedback now

Dave Longley: Intro could explain how JSON-LD can be used to switch between different contexts.

Manu Sporny: Moving on on the "the difference is in their context information".

Dave Longley: The example is not clear if you're not looking at details. Markus changed it. But that doesn't really highlight the primary function of expansion which is to remove the context.

Markus Lanthaler: right. At the moment, it's very confusing.

Dave Longley: we may just need to pick up two different names for the "homepage" for instance.

Manu Sporny: Moving on to feedback on section 5.2

Markus Lanthaler: when you're processing the local context, it's more reasonable to process the remote context before you do anything else.

Dave Longley: The separation of concepts is more about doing I/O vs. doing something that is JSON-LD related.

Gregg Kellogg: From an algorithmic point of view, it goes well to say that you dereference the context and use that inline. Pre-fetching is certainly a good idea but that does not make the algorithm any simpler in my view.

Manu Sporny: I feel the algorithm looks simpler if all remote resources get retrieved beforehand.

Dave Longley: When someone tries to implement the algorithms, it makes more sense to process remote resources before. Perhaps not easier to read for an overview of the algorithms.

Gregg Kellogg: I don't really see that it benefits my implementation in any way.

Dave Longley: CPU vs. I/O issue.

Gregg Kellogg: An algorithm is not the place to specify that.

Manu Sporny: Agreement that we're going to put a note in the spec to say that the contexts may be retrieved beforehand but the algorithms won't mention that.

Dave Longley: [scribe missed the proposal]

Manu Sporny: Sections 5.2 and 5.3. now read well. Moving parts will make things very chunky.

Markus Lanthaler: that would just add a couple of steps to the algorithms and general solution.

Manu Sporny: OK, général agreement on 5.2 then.

Dave Longley: I didn't find it confusing.

Markus Lanthaler: ok, fine for me if it's clear for everyone else. It's basically the first step so a bit confusing.

Dave Longley: Problem is about recursing. It may not actually happen anymore though. I'll take a look at that.

Gregg Kellogg: I can't have context that uses "language" as an alias for "@language". That's not a legitimate aliasing.

Dave Longley: OK, if it's removable, let's remove it.

Manu Sporny: If it's not, we could clarify why we need to mark it as "defined"

Dave Longley: The introduction was changed, so I thought this was checked.

Markus Lanthaler: I think the problem was about term definition inheritance.

Dave Longley: That should be removed now.

Markus Lanthaler: I'll have a look after the call.

Manu Sporny: OK, moving on towards the bottom of section 5.4.

Dave Longley: Gregg recommended re-ordering. I'm fine with that change.

Gregg Kellogg: In my implementation, it's logical to have them under context evaluation.

Dave Longley: OK, I would not introduce a new EvaluationContext term.

Gregg Kellogg: No. I would reorganize under 5.3.

Markus Lanthaler: Then we will end up 5-6 level deep which would be annoying.

Manu Sporny: Top level content processing algorithms would be good as Markus suggested.

Manu Sporny: I propose to stop here for this week, to let the editors catch up. My assumption is that when the whole list is checked off, we'll be in good shape for an FCGS.

Markus Lanthaler: one big issue is error handling. Completely missing for the time being.

Dave Longley: Markus, if you can take the error text that you had and add that to wherever we say "otherwise, it's an error", I'd be fine with that.

Markus Lanthaler: Just add that error constant?

Dave Longley: In the previous version, you called out precise errors.

Markus Lanthaler: At least Gregg was not too happy about that.

Manu Sporny: Your issue, Gregg, was saying that the algorithms should raise an error.

Gregg Kellogg: twofolds. Raise an error within an algorithm is not a pure algorithm. Other part is binding a specific token for the specific errors that were raised is also not a good idea.

Markus Lanthaler: http://json-ld.org/spec/latest/json-ld-api/#idl-def-JsonLdErrorCode

Dave Longley: Phrases instead of contents in the algorithms then

Gregg Kellogg: yes

Markus Lanthaler: I don't really see any difference to what we did last time.

Manu Sporny: It's one more level of indirection that I don't think we really need.

Dave Longley: I don't think it adds any more level of indirection. It should be almost the same as what Markus did before except we're dropping the constants.

Markus Lanthaler: What do we do after detecting an error, then?

Gregg Kellogg: That's a good question. There are cases where I raise errors and they are ignored, and vice versa.

Markus Lanthaler: I think all errors enumerated here are fatal errors.

Gregg Kellogg: "invalid container mapping", I could go on.

Markus Lanthaler: then we can ignore everything.

Manu Sporny: I think we'll have to go down any single one of these errors and decide which ones are fatal.

Dave Longley: In the meantime, I suggest pulling what Markus had and insert the appropriate term definition and link to this table.

Markus Lanthaler: ok.

Gregg Kellogg: Before we close, a little update on "tref".

Markus Lanthaler: just an update that reSpec does not run anymore for the time being.

Manu Sporny: Syntax spec is broken due to: Uncaught Reference to undefined term 'compact_iri'

Gregg Kellogg: One other thing to the updated 2 RDF algorithms. One test fails for me.

Dave Longley: I'll probably re-implement what you've been doing.

Gregg Kellogg: the convertFrom algorithm is not really different. The convertTo algorithm is substantially different.

Manu Sporny: Alright. Dave will have feedback when he implements it.

David I. Lehn: bye