Manu Sporny: Dave Longley and I are going to go through and clean up the algorithms near Dec. 15th
Markus Lanthaler: I'm going to update my JSON-LD processor this week, I hope to update the algorithms as well.
Niklas Lindström: Hopefully, I'm going to have time to get back to the RDFa Labs stuff (which is JSON-LD under the hood)
François Daoust: [one thing to clean up: remove statements such as "If context is a string, it must have a lexical form of IRI" since that's a syntax consideration (and it's defined in the syntax spec), not a processing step]
Niklas Lindström: I copied some of the JSON-LD implementation stuff as a result, if I have time I will be able to read through it and comment on it. I'd really like to be able to factor out the framing stuff.
Topic: ISSUE-157: JSON-LD mapping to RDF terminology
Markus Lanthaler: I took an action to take over the RDF re-write, I put something in the syntax spec which is more-or-less what Richard has in his draft. It has a few clarifications and some things he misunderstood.
Markus Lanthaler: That should explain the whole data model in all of it's detail and make it easy to map it to RDF. The relationship to RDF section is quite short at the moment, there are not many differences.
Markus Lanthaler: We need some reviews of those two sections, don't know if they're happy with it yet.
Manu Sporny: We strongly advise against using bnodes for properties, right?
Markus Lanthaler: yes.
François Daoust: Just one comment - we had removed MAY SHOULD or MUST from the data model. There should be constraints on the syntax itself, but not the data model.
François Daoust: It's fine to say that the data model will be an IRI... but the grammar section should say SHOULD NOT use a bnode.
Discussion about data model section, relationship to RDF, and ensuring that we address all of the issues brought up by the RDF WG. The group believes that the changes will address everything raised by the RDF WG.
Topic: ISSUE-184: Definition of JSON-LD processor in the API spec
Markus Lanthaler: In general, I introduced a product which is a JSON-LD processor, which is the only product that the spec defines.
Markus Lanthaler: I didn't say anything about parsing because a processor normally uses a JSON parser for parsing.
Markus Lanthaler: I didn't say anything about transforming data to a dataset or anything else - it just transforms the document. I'm not sure if that's enough.
Manu Sporny: I thought we'd have two classes of product: A "JSON-LD processor" and a "JSON-LD API implementation" (or some other name). [scribe assist by François Daoust]
Niklas Lindström: Could you say something like: your JSON-LD processor must be compliant with the algorithms, it can also be be compliant with the API
Manu Sporny: I think we should have two products, seems like two different things.
Markus Lanthaler: Why would you want to do one and not the other?
Niklas Lindström: Some programming languages make it difficult to implement the asynchronous API.
Manu Sporny: Some developers would rather have a synchronous API, which we're not going to spec out. We also want to leave room for people to innovate on the API portion, as we may not provide something that is the best API for certain use cases.
François Daoust: This is a way to defend the API - it's a way to keep the API in the spec, having two products. Not having two products will create a wall in the RDF working group - only need algorithms, don't need the API. Not having the API tied to a product diminishes its value in the spec.
Markus Lanthaler: Could we have two levels of implementation? Level 1 and Level 2.
Niklas Lindström: This is like having a processor supporting XML Infoset... and then having a DOM implementation on top of that.
PROPOSAL: The JSON-LD API specification will define two products: 1) A JSON-LD Processor, and 2) An Implementation of the JSON-LD API, which is dependent on a valid JSON-LD Processor implementation.
Niklas Lindström: .. 1) A JSON-LD Processor, and 2) A JSON-LD API compliant Processor…?
Manu Sporny: What about 1) A JSON-LD Processor, and 2) A JSON-LD Processor and API ?
Markus Lanthaler: maybe, a "JSON-LD Processor conformant to the JSON-LD API" or a "JSON-LD Processor implementing the JSON-LD API"
Niklas Lindström: 1) A JSON-LD Processor, and 2) A JSON-LD API implementation, which is a JSON-LD Processor
PROPOSAL: The JSON-LD API specification will define two products: 1) A JSON-LD Implementation, and 2) A JSON-LD Processor, which is dependent on a valid JSON-LD Implementation.
Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +0.5
Niklas Lindström: +1
François Daoust: +1 (equally happy with other terms)
RESOLUTION: The JSON-LD API specification will define two products: 1) A JSON-LD Implementation, and 2) A JSON-LD Processor, which is dependent on a valid JSON-LD Implementation and implements the asynchronous API.
Manu Sporny: Initially I had wanted us to try and figure out a way that a developer could signal that they wanted certain recoverable errors to be recovered automatically, or they'd provide the proper interpretation, or they would signal that processing should stop. A number of folks felt that was overkill, so the proposal on the table is to simplify the error mechanism to just a simple error callback mechanism with an error code and a message.
PROPOSAL: Simplify the error handling by passing an error object to the callbacks which only consists of an error code and an optional error message containing additional information for debugging.
Markus Lanthaler: +1
Niklas Lindström: +1
Manu Sporny: +1
François Daoust: +1
Gregg Kellogg: +1
RESOLUTION: Simplify the error handling mechanism by passing an error object to the callbacks which only consists of an error code and an optional error message containing additional information for debugging.
Manu Sporny: Do we halt on recoverable errors?
Markus Lanthaler: if it's recoverable, is it an error?
Gregg Kellogg: Yes, for example - list_of_lists is recoverable, but it's also an error.
Gregg Kellogg: I have a feature in my processor which is a 'validate' mode.
Niklas Lindström: Should the processor stop processing the local object, but continue on error?
Gregg Kellogg: I feel like we should process as much as you can, so you can find as many errors as you can.
Gregg Kellogg: A way to say 'stop processing' when you encounter an error is useful.
Gregg Kellogg: We can have a runtime flag to say "stop when you hit an error" or "continue if you can, on error"
Manu Sporny: I have a problem if we're going to start halting on errors that should be recoverable. If the XHTML vs. HTML5 debate has taught us anything, it's that processors should try to go as far as they reasonably can, sometimes changing the output drastically in order to not throw an error and "fix" the input to be something reasonable.
Markus Lanthaler: Yes, but if we do that, the algorithms are going to get far more complex... we have to cover every error case and how to recover from it.
Manu Sporny: I see your point, but I think that would be better than halting.
Gregg Kellogg: I think we need at least two levels of errors - errors and fatal errors. We want to give folks warnings that their input is broken in some way and we "fixed" it.
Markus Lanthaler: At the moment, the algorithms are defined for well-formed documents only. It's up to the processors to produce warnings if they want to, but they can do that however they want to.
Manu Sporny: I think that we should use this error/issue mechanism to report both warnings and errors.
Markus Lanthaler: Then we risk having this issue drawn out for a much longer time - this issue has already taken a long time to deal with.
Markus Lanthaler: The reason this issue has been open for such a long time is that it's difficult to define error behavior for each of these cases.
Gregg Kellogg: I think the reason is the complexity of the API callback, not having error recovery conditions.
Niklas Lindström: We need something like: "it is an error to use @type and @language in the same element. If that happens, a processor should ignore [one of them] and issue a warning." I.e. that is a usage error but doesn't result in a processor error, only a warning? What are the fatal errors?
Niklas Lindström: I'm wondering where we're going here - the second proposal seems like it may or may not prohibit "Processing MUST be stopped after an error is triggered".
Gregg Kellogg: in RDFa, we recently agreed to describe the redefinition of a prefix as a warning. This may come up in JSON-LD as a warning.
Gregg Kellogg: malformed IRIs can also be warnings.
Gregg Kellogg: A processor should be able to classify that as an error, but a non-fatal error.
Niklas Lindström: I'm thinking of the two different situations, where you have a JSON-LD processor (one is during development - you may have odd data - raise a warning and continue on errors)... in production mode, you might want to halt on the first warning/error. I wouldn't want to define something in the spec where one of these cases is excluded.
Markus Lanthaler: In development, you want more debug output - it's not just about warnings/errors. I don't think we need to specify that in the spec.
Markus Lanthaler: It's dependent on implementations - some might want to debug, do warnings and errors.
more discussion on how to get warnings to developers.
Gregg Kellogg: I think we need 'warnings', 'errors', and 'fatal errors'
Niklas Lindström: You could just deal with this in the error callback - throw an error if you want to stop, don't do it if you don't.
Gregg Kellogg: The issue here is we need some way of saying 'warnings', 'errors', or 'fatal errors'.
Markus Lanthaler: What would need to be added?
Gregg Kellogg: We just need a flag on the 'error', stating whether it's a 'warning', 'error', or 'fatal error'.
Manu Sporny: We've burned a lot of call time discussing this. Let's go back to the issue tracker and get some concrete proposals down, straw-poll those through the issue tracker, and revisit this issue when we have something solid we can propose.
Manu Sporny: The RDF WG has kicked this issue back to us and told us that we need to drive the issue. I think we're all in agreement here on what needs to be done. So, let's see if we have consensus here, and if we do, we'll tell the RDF WG that this is where we have consensus.
PROPOSAL: State in the syntax spec that JSON-LD can be used as a RDF graph source. A consumer would just use the default graph and ignore all named graphs in that case. This would allow a server to use, e.g., both Turtle and JSON-LD in content negotiation.
RESOLUTION: State in the syntax spec that JSON-LD can be used as a RDF graph source. A consumer would just use the default graph and ignore all named graphs in that case. This would allow a server to use, e.g., both Turtle and JSON-LD in content negotiation.
Gregg Kellogg: This resolution is still a bit problematic. For example, in many of the named graphs cases, the default graph would only contain provenance information... the actual data would be contained in a named graph. This is problematic, so maybe servers would have to serve their data in a different way.
Niklas Lindström: The issue with named graphs is that you use them in a different way when you manage your data internally. That's how you handle the quoting of the dataset stuff...
Niklas Lindström: When you ask the system for the JSON-LD document for a named graph, you would get the information from that back in a default graph.
Gregg Kellogg: Well, another proposal I put forward was [scribe missed]
Manu Sporny: I think the problem here is that there are many ways to use named graphs and we can't suggest something that is going to work across the board. What we might do is tell people the following: If the top-most JSON Object contains a '@graph' keyword, use that as the 'default graph', if it doesn't contain a '@graph' keyword, use the top-most JSON Object as the default graph. If we do that, then we don't hit the issue that Gregg mentions above.