Gregg Kellogg: Probably going to visit Wikimedia Germany - going to talk to them more about JSON-LD and Wikidata during that trip. [scribe assist by Manu Sporny]
François Daoust: TPAC coming up and of October, last year there were lots of break out sessions, and we're looking for ideas
… I wonder of someone could run a breakout session on JSON-LD
Topic: TPAC JSON-LD breakout session
Manu Sporny: it would be good to do, but it doesn't seem like anyone has the time to go.
Gregg Kellogg: Maybe a BOF? [scribe assist by Manu Sporny]
Manu Sporny: perhaps we can make ourselves available over Skype, if there's a BOF.
… of course, if the connections bad, it might not be worth it.
François Daoust: [I will try but I doubt there will be bridges available during the plenary day]
Topic: RDF WG review of latest JSON-LD docs
Gregg Kellogg: I got an issue put on me in order to get a plan together for a review from the RDF WG from folks who hadn't reviewed it yet. [scribe assist by Manu Sporny]
Gregg Kellogg: Richard and Sandro volunteered to review the documents. I didn't know the status of the docs at the time, need to understand the status. [scribe assist by Manu Sporny]
Gregg Kellogg: We need the timeframe/plan for the syntax spec to be available for review. [scribe assist by Manu Sporny]
Manu Sporny: we have some resolutions that we can apply to the spec, which would put both syntax and API in good shape
… We could theoretically have a review ready spec by next week.
… There are still some outstanding issues, but we can just put issue markers in
Gregg Kellogg: I think synchronizing the status of the spec w/ the latest issue resolutions would be good. [scribe assist by Manu Sporny]
Gregg Kellogg: I think we also decided on language maps - don't know if we have them documented. [scribe assist by Manu Sporny]
Manu Sporny: cygri took the action to align the doc with RDF Concepts. We can do everything else.
Manu Sporny: They're in the syntax spec... not in the API spec. [scribe assist by Manu Sporny]
… Since Richard is reviewing the document, maybe he would also make sure the two docs are aligned.
Markus Lanthaler: shouldn't we decide how language maps and property generators are going to be implemented before asking for review?
Manu Sporny: they're reviewing the syntax, and not the API, so it might not be important.
ACTION: Manu to ping Richard on JSON-LD Syntax and RDF Concepts terminology alignment.
Markus Lanthaler: there haven't been many changes since the last rounds of reviews, so I don't know how much sense it makes to do a review.
Manu Sporny: that's what diffmarks are for. However, people like Sandro, who haven't done a review, end up doing a full review.
… I think there will be significant changes to the intro.
ACTION: Manu to update JSON-LD Syntax spec and integrate changes from issue tracker.
… They can search the document for the value. Even if they needed to do that, they can search for the reference.
Niklas Lindström: if you give them the term string, they can check the context.
... We could give root, parent, key and value. Then you don't need JSON pointer.
Niklas Lindström: minimum should be term and value, if possible parent and root.
Manu Sporny: with just key and value, it is still ambiguous
… If we don't want JSON pointer, we need to be sure we have something that does the same thing.
… for that to happen, it needs to be more than the key and the value.
Gregg Kellogg: This is exactly what JSON Pointer is designed to do. [scribe assist by Manu Sporny]
Niklas Lindström: .. we can give them a path which is an array of strings and numbers
Niklas Lindström: .. that is enough to find the exact value from the root
Niklas Lindström: .. that would be path: [@graph', 0, 'title', '@value']
Manu Sporny: I don't want to hold up JSON-LD just because JSON Pointer hasn't reached Rec.
Niklas Lindström: I think that using a string to represent the path is overkill.
… The result of that parsing is something we can already produce.
François Daoust: I have manu's concern as well. We could easily be blocked because of that status of JSON pointer, and this is not core to the API.
… I was warning if we could make this informative to suggest that implementations ought to (in a non normative way, that is) use JSON Pointers.
Markus Lanthaler: I'm worried that we're going too far. You would have to know the internals of the processor to make use of this.
… Either you program the error handler to deal with a specific situation or ???
… Perhaps we should keep it simple with an error type, message and return value to continue or stop.
Manu Sporny: so, this would mean that an implementation couldn't hope to correct data at runtime.
Manu Sporny: I get where francios is going, but I don't think we can be informative in this case.
… It's like saying there's an optional feature.
… this means you need to reference a normative spec.
François Daoust: I don't have a good example right now, and you may just end up with something you don't like.
François Daoust: I'd rather leave it as is and allow the spec to move forward.
Gregg Kellogg: In RDFa, we provided different ways to specify alternative information. Perhaps there is a way to have some options that can be added that allow stuff like this to be specified. If you're going to do that, and it's not normative, it's probably not that useful. [scribe assist by Manu Sporny]
Niklas Lindström: I appreciate markus' point. Perhaps we can allow for the return to be true or false and not allow for any correction.
Manu Sporny: I still think we should use the data structures I proposed. I like the simplicity of Markus' approach, but I'm concerned that there is no way to do correction.
… Correction seems to be associated with corner cases. But, as Markus said, you could just run a pre-processor over the input to make sure it is in the proper order.
Niklas Lindström: if we provide path information for global processing, it can lead to strange scenarios. If the path information implies that you can do correction, it's better to do a different way.
… we should have more demand before we add such a feature.
Manu Sporny: we could keep type and operation. Remove data.
… Return value is true or false, to ignore and continue or abort.
… The alternative is to allow the return to be different things, either boolean or object.
Gregg Kellogg: We might be boiling this down a bit too much if we do true/false. Perhaps we need to keep the return type being an object to ensure the greatest amount of future proofing. [scribe assist by Manu Sporny]
Gregg Kellogg: You could just throw an exception - ignore or abort the entire operation via an exception. [scribe assist by Manu Sporny]
Niklas Lindström: it doesn't matter where it happens, as it's synchronous.
… If you don't have an error handler, you would just throw the original exception.
Gregg Kellogg: The error handler is a function that is called, it's not something that intercepts an exception. [scribe assist by Manu Sporny]
Manu Sporny: I don't think we want to use this as an exception intercept. We did this to allow the developer that option.
Markus Lanthaler: we did the error handler because it's asynchronous, not synchronous.
Manu Sporny: I'd expect that when the processor stops it does this by throwing an exception.
Gregg Kellogg: The reason we went down this path is because we wanted the developer to have more control over the error handling process. [scribe assist by Manu Sporny]
Gregg Kellogg: The way that we had thought processing would stop (with an error) is with the processor returning an exception. [scribe assist by Manu Sporny]
Gregg Kellogg: if the programmer wants to do anything else, the developer should throw an exception. [scribe assist by Manu Sporny]
Gregg Kellogg: I think we should return a structure that includes some information that may be used by the processor in the future to provide finer granularity, but at this point, the actual return content is ignored and the current input is ignored and you continue processing the input stream. If the user wants to stop processing, they throw an exception. [scribe assist by Manu Sporny]
Niklas Lindström: what happens when an exception is thrown we're in something asynchronous, you can't catch it.
Manu Sporny: the original caller won't get the exception, but that happens all the time in JavaScript.
Manu Sporny: We could make this the method signature - function handleError(err, callback)
Manu Sporny: if you want to pass along the error, you do this - callback(err)
Manu Sporny: if you want to ignore the error and continue, you do this - callback(null, {})
Manu Sporny: there's a standard way to do errors in node.js. If you look at the async library, this pattern of having error and callback as arguments is well established.
… If we want to do things asynchronously, this is the way to do it.
… if there's an error, 'handle error' is called with the error and a callback. This allows the error handler to notify it's completion by calling the callback.
Niklas Lindström: this is not the way error handler callbacks are used in other libraries, like XMLHttpRequest.
Manu Sporny: that's an old design, and people have moved away from that.
Niklas Lindström: unless the handler is going to do something asynchronous itself, this looks like serious overkill.
Markus Lanthaler: before the handler returns, the processor can decide whether to continue or not.
Manu Sporny: all node.js libraries are designed like this.
Dave Longley: i don't think we want to prohibit asynchronous behavior in the error handler -- especially when the rest of the design for the JSON-LD API is asynchronous
Dave Longley: you might want to make other JSON-LD calls in the error handler ... or do anything else in an asynchronous way; if we're not consistently supporting async ... then we're not supporting async; it's going to be very frustrating for people who need it
Dave Longley: (as in, they'll have to rewrite the processor)
Dave Longley: i think it's a bad idea to mix and match async w/sync... because it just means that it won't always work
Manu Sporny: I don't think there's anything to prevent the processor from continuing to process.
Markus Lanthaler: either you stop processing, or you have a callback state to start and restart.
François Daoust: you mentioned that it is common practice, but I'd like to see an example.
François Daoust: in the async world, the error handler signature doesn't take a callback.
… handle error is already a callback.
… This is only necessary if the error handler needs to be asynchronous itself.
… I don't think that a error handler callback itself using a callback is that common.
Manu Sporny: but sending a callback for something that should execute asynchronously is common.
Dave Longley: as soon as you force synchronicity into an asynchronous system you've broken it -- which means that you've prohibited yourself from using the same async APIs that do things for you in your error handlers that you use everywhere else
Markus Lanthaler: I wanted to ask if we should postpone until we have more information.
Manu Sporny: we never got around to discussing this in depth.
… I think we said that there were issues with compaction, as it could be combinatorially complex to run, and we may want an option to tell the API to do this, or not.
Niklas Lindström: I think we should probably resolve issue 113 first.
… Based on that, we can decide on issue 160.
… that will tell us if it is feasible to do something that isn't "high fidelity"
Markus Lanthaler: as there might be more information under a language, I don't know if it's even feasible.
Niklas Lindström: when we introduced property generators we said that it was likely that we wouldn't use it for compaction at all.
Manu Sporny: the crux of the issue is that data gets created.
… drupal community wants to be sure that if the compact, they get the same thing. We said we'd given them a flag to allow this.
Gregg Kellogg: I think we could accomplish this by just picking the property-generator term before all other terms. [scribe assist by Manu Sporny]
Gregg Kellogg: We may also want to implement duplicate removal as well. [scribe assist by Manu Sporny]
Niklas Lindström: I realized that what gregg said makes sense: given a flag, property generators should only be used on data which you know about in advance. You shouldn't use them otherwise.
… Given that, we could simplify the algorithm by just using the first value in the property generator, because you expect (require) that the data be consistent with doing that.
… If a flag is used, you won't accidentally use that.
… The flag should enable the use of property generators in compaction.
… by using try, you're prepared that every term that has a property generator will only create round-trippable data if your input has duplicate data for all values.
Manu Sporny: if you use gregg's algorithm, it is linear and not combinatorial.
... The key thing is that in the term selector you have to use property generator terms first.
... If we follow a standard selection process, it is linear.
Manu Sporny: modify compaction algorithm to consider property generator terms before any other term.
… any time you find something that matches, you check to see if it already exists and if it has that value. If it does, you ignore it, otherwise, you add to the end of the array.
Markus Lanthaler: What about @lists - do we check all entries in there? [scribe assist by Manu Sporny]
Manu Sporny: Yes, I think we have to. [scribe assist by Manu Sporny]
Gregg Kellogg: Yes, and keep in mind that list order is important. [scribe assist by Manu Sporny]
Niklas Lindström: if there's a value, you need to check all keys in the value.
… If there's an ID, the expressed information is enough.
Markus Lanthaler: this doesn't guarantee that the node definitions are equivalent.
Niklas Lindström: I have a problem with expanded forms not always being flattened anyway.
… For this case, it would really help.
… we could say that to not loose data, it needs to be used with 'flatten' set to true.
Niklas Lindström: drupal wants this because the use RDFa, and this is consistent with the use in RDFa.
… what they don't care about is the potential of using vocabulary expansion, which could be done on the RDF side.
Manu Sporny: it seems we have a solution, but it still has complexities due to complex values.
… We can implement a basic version of this, but if we find deeply nested objects we can throw an exception.