Manu Sporny: An attempt to address some of the other concerns that people have.
… First thing where pre-processing might apply would be to split an array into properties where each positions in an array is mapped to different properties
… (example of location)
… We could add a mechanism in JSON-LD that explicits the mapping.
… A more generic way of doing this is to add a pre-processing step where a function gets called during expansion to do the mapping.
… That would allow us to support this mapping without having to put the explicit mapping.
… The argument against is that people can already do it by running a pre-processing step themselves.
… What do people think? No pre-processing? declarative? pre-processing function?
Niklas Lindström: I'm for declarative only or nothing.
… You can already do that.
… I also fear that to some extent any arbitrary JSON may be JSON-LD given some pre-processing hook.
… The only way to understand the JSON would be to have declarative mechanism.
Gregg Kellogg: I'm of the same opinion. I also think that it's not necessary.
… It just doesn't really do anything.
… It basically says: run any arbitrary code you want.
… It doesn't really provide any useful thing for authors. They won't know how to implement that given some context.
… I agree that if we want to support something like this, it should be a declarative mechanism.
Manu Sporny: others?
Markus Lanthaler: I agree.
Manu Sporny: The argument in favor is to give developers some hook to think differently, to know how to do it.
… They might think: "Oh, I just need to implement that pre-processing step to convert my JSON into JSON-LD".
Niklas Lindström: I think that there might be general transformation specs around that might be more applicable to that case.
François Daoust: Having given this some thought - there is one thing that developers very often use... [scribe assist by Manu Sporny]
François Daoust: The .replace() function in JavaScript... you can change data in any way that you want - you can use a regular string, or you can use a function... it's more flexible. It gives developers some flexibility [scribe assist by Manu Sporny]
François Daoust: From an external point of view, the declarative mechanism seems too complex, with not much added value. [scribe assist by Manu Sporny]
Gregg Kellogg: good use for the Wiki to reference techniques.
Manu Sporny: indeed, totally agree with Gregg.
Nicklas: I think that we should be careful about this notion in the spec. The purpose of JSON-LD is to find the precise semantics of a document and this all relates to arbitrary consumption of it.
Markus Lanthaler: don't know if you guys saw it.. I added a "Publications / Articles" and "Presentations" section to the homepage: http://json-ld.org/#publ
… You can always say JSON + code = RDF.
Markus Lanthaler: I don't think we need a wiki (yet)
Manu Sporny: mlnt, Yep saw it - good work and we should use that.
Manu Sporny: So proposal is: do not support a pre-processing step option in the JSON-LD API
PROPOSAL: Do not support a pre-processing step option in the JSON-LD API to transform incoming JSON.
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
François Daoust: +1
David I. Lehn: +1
RESOLUTION: Do not support a pre-processing step option in the JSON-LD API to transform incoming JSON.
Topic: ISSUE-146: Support array position to property binding
Manu Sporny: This is the reason why we started with ISSUE-149 since it would have solved this one.
… The argument is that they have a bunch of data with lat/lon coordinates and they don't want to be overly verbose in their data, adding lat/lon properties. They'd like to work with data in their native form, as lat/lon couples.
… The request is thus to support a declarative way of being explicit about the mapping.
… Do we feel that it is something that is acceptable?
… I don't think they'd be happy if we don't support but the previous point about introducing complexity stands.
… Any thoughts on this? Should we add it right now? Later on? Not at all?
Gregg Kellogg: One of the strongest objections against pre-processing was that it should have been done at the RDF level.
… One way that this could be done is to use a list form, SPARQL, and… [scribe did not get the explanation]
… There's also a tendency that JSON-LD is looking too much at having the spec adopted by anyone, adding everything to please everyone.
… In this case, the tuple position seems to be very domain-specific.
… I think there are other ways to do that.
Niklas Lindström: even in JSON, using property names as keys is more common.
… Also there might be more interest to define a vocabulary to describe such things.
… Question is whether to keep this on the proposition list for a potential JSON-LD 1.1. I had this issue when I saw geo-json.
… I think of SPARQL as a good success going to 1.0 without adding new ideas that were quickly finalized afterwards in 1.1.
Manu Sporny: I agree with everything that has been said so far. The argument that they can do the transformation in RDF and SPARQL, I don't think that this is acceptable to developers all around toying with JSON-LD.
… I don't think that telling them to mess with RDF or SPARQL is good idea.
… So proposal is to not support a declarative mechanism to support such mappings.
Gregg Kellogg: If we have a very SPARQL-like mechanism in JSON, that could be very useful. For another spec.
PROPOSAL: Do not support a declarative mechanism that is capable of mapping array position to an RDF property.
Markus Lanthaler: +1
François Daoust: +1
Manu Sporny: +1
Gregg Kellogg: +1
David I. Lehn: +0
Niklas Lindström: +0.5 (since I like it, but probably not for 1.0)
RESOLUTION: Do not support a declarative mechanism that is capable of mapping array position to an RDF property.
Topic: ISSUE-147: Add synchronous methods to the API
François Daoust: Looking at another WG API - API design cookbook. [scribe assist by Manu Sporny]
François Daoust: This section is empty for the time being... [scribe assist by Manu Sporny]
François Daoust: We should get in touch with the editor... [scribe assist by Manu Sporny]
François Daoust: I'd prefer asynchronous-only, but Robin may have useful feedback for us. [scribe assist by Manu Sporny]
Niklas Lindström: in Python, it's not common at all to pass callbacks. It's more common to have a "sync" parameter.
… Asynchronous code is harder to read.
… Of course, there may be a case where you have external context.
… I would favor a situation where, when you have no callback, you would trigger the synchronous mode.
Manu Sporny: interesting idea. That would keep the same signature between functions.
Gregg Kellogg: That's basically how things work in Ruby.
… although more common to use a block.
… A reasonable approach is to provide a behavior when there is no callback
Gregg Kellogg: that does complicate things a bit.
Niklas Lindström: note that in JavaScript, it might be difficult to convert from asynchronous to synchronous.
François Daoust: I would be against a different behavior based on a parameter in a function - switching between async vs. sync... [scribe assist by Manu Sporny]
François Daoust: I think developers forget parameters every now and then, I'd rather not go down this path. [scribe assist by Manu Sporny]
François Daoust: If we decide to go down that road, I wouldn't use the same function for both. [scribe assist by Manu Sporny]
François Daoust: Or, we would want an explicit parameter. [scribe assist by Manu Sporny]
Niklas Lindström: I don't think it's that uncommon.
François Daoust: I can't think of an example in JavaScript. [scribe assist by Manu Sporny]
Manu Sporny: I have never seen any of the core Node.js API doing any of this. I do agree with Francois that it would be dangerous to change the behavior just because you forget a parameter.
… On one case it's a neat trick because it keeps signature consistent, but changing the behavior based on the presence of a parameter is dangerous.
… We could mention the synchronous methods informally without spec-ing them in Web IDL.
… I.e. to add documentation to the JSON-LD API that the core Web IDL is going to be only asynchronous, but that if the developer wants to add synchronous interfaces, they could add "Sync", remove the callback and return the result of the call.
[discussion around asynchronous/synchronous in different languages]
François Daoust: I was looking at the JSON-LD API document, at .compact() and .expand() - what about the error mechanism? There are callbacks there, right? [scribe assist by Manu Sporny]
François Daoust: You can't throw an exception while you're in a real asynchronous call... if something wrong happens, you can't just throw an exception and catch it from the main thread. [scribe assist by Manu Sporny]
Markus Lanthaler: we already resolved this, see link above
Niklas Lindström: .. another example of "synchronous" when no callback is passed: http://ajaxrpc.com/
François Daoust: ok good, thanks!
Manu Sporny: Going back to the initial problem.
… In JavaScript, there is almost never a good reason to be synchronous. In Python, it's a bit of the contrary. There are good arguments either way. I still think we should provide asynchronous methods only.
… The error mechanism is problematic as well. You cannot simply return an exception to stop the execution.
Niklas Lindström: In general, I think that asynchronous APIs are more complex.
Manu Sporny: I believed that three months ago, but think the other way around.
… now that I've played with Node.js. I hated it in the beginning but now wish that Python has asynchronous interfaces the same way.
Niklas Lindström: adding a callback does not mean the function would be asynchronous.
Manu Sporny: true.
Markus Lanthaler: s/Niklas/Markus
Manu Sporny: if the developer forgets to include the callback, it's going to act completely differently. Though we may say they are using the API incorrectly.
… The proposal becomes "The API signature across all languages is exactly the same. If you want to have synchronous behavior, just don't add the callback parameter".
Niklas Lindström: I like it better although I very much respect the notion of code errors.
… Maybe we should look at other APIs.
François Daoust: +1 to reach out to other groups that produce APIs.
Gregg Kellogg: We could add a note to the spec asking for feedback.
PROPOSAL: The JSON-LD API method signatures across all languages are exactly the same. If a developer wants synchronous behavior, they MUST NOT add the callback parameter. Add an issue marker to the JSON-LD API spec stating that this functionality is at risk.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
François Daoust: +1
Markus Lanthaler: -0.5
David I. Lehn: +0
RESOLUTION: The JSON-LD API method signatures across all languages are exactly the same. If a developer wants synchronous behavior, they MUST NOT add the callback parameter. Add an issue marker to the JSON-LD API spec stating that this functionality is at risk.
Manu Sporny: Note that we intend to explore this mechanism further before finalizing the API spec.
Topic: ISSUE-80: Remove initial context from API spec
Markus Lanthaler: last resolution was: If JSON-LD has an initial context, it MUST be specified external to the JSON-LD Syntax specification at a well-known location.
Manu Sporny: There was a proposal where the initial context would have @type and @graph.
… Do we have a use for the initial context? I think that we don't at this point, really. We can always introduce an initial context.
… The initial context would future-proof the language. That's why it's there in RDFa. But I don't think that's needed for JSON-LD.
… The proposal is not to support the initial context in v1.0.
Gregg Kellogg: there's a big push for us to reach feature freeze. I think that not putting it in now would mean it's going to be hard to add it back later on.
… I think it's valuable to have it in there even if it's empty for the reason you mention about future versions.
… I've seen some arguments on the RDF mailing-list that we should leave this for now and add it back in v1.1 or v2. Similarly, this would make it difficult to roll back on that decision later on if we don't keep it in the spec.
… And then at some point in the future, we may discuss whether it makes sense to define prefixes or the like.
Markus Lanthaler: Why do you see a problem to bring it back later on?
… It's mentioned once in all the algorithms?
Gregg Kellogg: I'm thinking just from a procedure point of view.
Markus Lanthaler: The way it's written, it's useless.
Gregg Kellogg: I think that's something we need to address, to give a way for it to be modified outside of the spec.
Markus Lanthaler: Not sure I want to see that.
Niklas Lindström: It is more confusing for authors. It would be simpler if we didn't have it here. You have to monitor that context.
Manu Sporny: If we had an initial context, it would be completely outside of the spec, maintained by Ivan.
… The initial RDFa context was really useful to convince large companies to support RDFa.
Dave Longley: any security issues? does the initial context live at an HTTP endpoint vs. an HTTPS one?
… The problem is more political than technical. Pure extractors are not going to extract data from a document that is not explicit about its initial context.
… It seems that it would be a bad move not to have a mechanism to correct this.
… I agree with Markus that it is not going to be a big deal for JSON-LD as it was for RDFa.
Dave Longley: seems like a potential security problem to require all JSON-LD processors to hit an insecure endpoint to initialize themselves
Gregg Kellogg: I don't understand how that works if it's in the spec.
Manu Sporny: My preference is still to add a URL for an initial context, and then leave it empty up until we need it. Not a big deal if it ends up not being used.
Markus Lanthaler: If we put it in there right now, we won't ever be able to drop it afterwards.
… That would then need that every JSON-LD processor would need to fetch the IRI.
Manu Sporny: Processors can cache the context.
Markus Lanthaler: But how do you fix the problem then?
Manu Sporny: Software updates.
… The overhead for starting a new group, creating the spec, adding the feature and starting to work on a standard is 9 month to 2-3 years.
Markus Lanthaler: I just don't see the real scenario that would pop-up for that.
… You use terms most of the time. Hopefully we won't have requests from large companies to put all terms in the initial context.
Markus Lanthaler: The other point is that it's easy to reference an external context through a URI.
Manu Sporny: good points on either side.
Manu Sporny: If large companies could agree on something such as schema.org, they are in a good position to drive the inclusion of the vocabulary in the initial context. We may not like that or want that, but that's how things go.
Niklas Lindström: It's easy for publishers to add all the terms from schema.org in their context.
Manu Sporny: interesting discussion that we already had in the RDFa WG. We should discuss again.
Markus Lanthaler: we already can do that with an optional context in expand/compact.