JSON-LD Community Group Telecon

Minutes for 2013-02-19

  1. ISSUE-217: Disallow BNode identifier as Graph Name
  2. Publishing JSON-LD 1.0 as a FCGS
  3. ISSUE-218: Algorithm specification updates by editors
  4. Update to RDF Algorithms
  1. This group re-affirms that the common practice when naming a graph is to use either an IRI or a blank node identifier. The JSON-LD specification remains unchanged. When expressing graphs in Linked Data, the graph name SHOULD be an IRI.
  2. Publish the JSON-LD 1.0 syntax specification as of February 19th 2013 as a Final Community Group Specification.
Manu Sporny
François Daoust
François Daoust, Manu Sporny, Niklas Lindström, Gregg Kellogg, Markus Lanthaler, Dave Longley, David I. Lehn
Audio Log
François Daoust is scribing.
Discussion about graph BNode identifier as Graph Name permathread.

Topic: ISSUE-217: Disallow BNode identifier as Graph Name

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.
… I'd like for us to make the statement that the ID of a graph denotes the graph in JSON-LD.
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.
… I think that we need to wait for the RDF WG to come to a final decision and see here what that entails.
Manu Sporny: Markus, Gregg, and myself, let's make sure we show up on tomorrow's RDF call then.
[more discussion on blank nodes and base document IRI]
Manu Sporny: OK, then waiting for the RDF WG to come up with a resolution.
… Do we want to do any kind of proposals? To state the solution that we believe would be the right one?
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.
PROPOSAL: This group re-affirms that the common practice when naming a graph is to use either an IRI or a blank node identifier. The JSON-LD specification remains unchanged. When expressing graphs in Linked Data, the graph name SHOULD be an IRI.
Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Niklas dreams aloud about an utopic world where something named RDF 2.0 would solve everyone's problems.
RESOLUTION: This group re-affirms that the common practice when naming a graph is to use either an IRI or a blank node identifier. The JSON-LD specification remains unchanged. When expressing graphs in Linked Data, the graph name SHOULD be an IRI.

Topic: Publishing JSON-LD 1.0 as a FCGS

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
PROPOSAL: Publish the JSON-LD 1.0 syntax specification as of February 19th 2013 as a Final Community Group Specification.
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Dave Longley: +1
François Daoust: +1
Niklas Lindström: +1
RESOLUTION: Publish the JSON-LD 1.0 syntax specification as of February 19th 2013 as a Final Community Group Specification.

Topic: ISSUE-218: Algorithm specification updates by editors

Manu Sporny: Markus has done a fantastic job at getting all our comments as a checklist in the issue tracker.
… Markus, could you give us an overview of biggest concerns?
Markus Lanthaler: basically the same as last week.
… Some typos have changed but the algorithms in general have not really been updated.
… Dave fixed a couple of bugs.
… Other things haven't been done or at least I haven't seen them yet.
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.
… Moving keywords processing around could be one such thing. It would be good to have feedback from others (Gregg?).
… Maybe folding keywords aliasing processing into IRI mapping. It would be fine with me as long as we make it clear that they are handled. Previous version did not seem to handle them at all.
Gregg Kellogg: My previous implementation folded the keywords aliasing into the normal term processing.
… I ended up doing it as a reverse table
… I haven't progressed enough in updating compaction to see that it clarified things or not.
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.
… Could you isolate points that need feedback from the group?
… To the extent possible, the editors should fix the spec. If there's disagreement or if you don't really know which way to go, flag that for the group to look at. Does that seem like a reasonable way to proceed?
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.
… I think lots of things related to the context should be close to the context processing section.
… I feel there is no movement because we do not have a good overview of what we want as a group.
Markus Lanthaler: I agree. I haven't made some changes not to have to revert the changes afterwards.
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".
… Moving on to "we" being used quite a bit
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.
… The comment about the relative IRI is related to passing the base IRI in the options parameter of the expansion algorithm
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.
… We can probably link to RFC something for IRI resolution.
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.
… Moving on to the "General solution" sub-section. I agree. Any disagreement?
[none heard]
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.
… It's reasonable to use that language, but maybe add a note that says MUST, SHOULD and etc. do not mean the same thing there.
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.
… the note should go in Context Expansion. [no disagreement heard]
… Moving on to Dave's feedback.
… Point on audience is correct, indeed. Developers might want to have a look at the API in the spec.
… [no disagreement heard]
… Moving on to the comment on features
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]
Gregg Kellogg: the test suite is referenced generically. We could get an EARL report in place to link tests and the spec.
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.
… We should need to change the examples to show how very different contexts can be used with the same data.
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.
… Moving on to 5.3.
Dave Longley: I didn't find it confusing.
… to mark the keys as having been defined.
Markus Lanthaler: ok, fine for me if it's clear for everyone else. It's basically the first step so a bit confusing.
… It gets clearer when you read on.
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"
… Moving on to section 5.4
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.
… Since then, I think the errors are defined as phrases. I think it's fine to include these phrases in the algorithms.
Dave Longley: Phrases instead of contents in the algorithms then
… Can we say that an "invalid syntax" has been detected?
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.

Topic: Update to RDF Algorithms

Gregg Kellogg: Before we close, a little update on "tref".
… [scribe missed points]
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.
… It's either a bug in my implementation or a bug in the flattening algorithm.
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.
… Thanks for the call everyone. We'll chat again next week.
David I. Lehn: bye
[call adjourned]