Create a pre-processing step option for the API

[msporny]

Should we add an optional parameter for all API calls that could pre-process all key-values found in JSON-LD API input in an arbitrary manner? For example:

function myFunc(key, value) {
  if(key === 'position') {
    return {'latitude': value[0], 'longitude': value[1]};
  }
};

jsonld.expand(data, {'preprocess': myFunc}, callback);

This approach would address issue #146, and may be useful for other sorts of migration that would otherwise complicate JSON-LD.

//cc @retobg

[gkellogg]

On the RDF call, Sandro strongly objected to this notion. We need to tread carefully. Personally, I think it's a matter or clarification, but I think it should be folded into expansion.

[lanthaler]

The question is whether this really needs to be attached to the API itself!? In my opinion it is trivial to write such a pre-processing step without having to resort to the official API or am I missing something?

[msporny]

@gkellogg I do think it's a matter of clarification as I don't see how a pre-processing step is that dangerous for data we don't intend to support. That is, people are going to do it anyway, and we need to formalize the best way to do it.

@lanthaler It's true that it doesn't technically need to be attached to the API itself. What we found, though, with RDFa Lite was that if you spell out certain features in the spec... even if they're fairly obvious to the folks that know the spec, people have an easier time accepting the "best practice" and using it. Otherwise, there can be confusion around what a best practice entails... and if the spec is silent on it, it can lead to people asserting that the intent was never to pre-process data that didn't fit the JSON-LD model. So, it always helps to be a bit more explicit in the specs with practices that we expect to see in the wild.

[lanthaler]

... I see it from the opposite side. I find it rather dangerous to declare constructs that would otherwise be un-conformant JSON-LD to best practices.

[retog]

If I understand correcty this would require any json-ld parser to be a js-interpreter as well. This seems quite a strong requirement to me. It would also imply new security considerations for jso-ld documents.

[msporny]

@retobg There is no js-interpreter requirement here... the pre-processing step would be implemented in whatever language the API is implemented in.

[retog]

Ok, I must admit I haven't studied the API in detail. Such an extension would not fit into the declared scope of the API of allowing to "programmatically transforming JSON-LD documents in order to make them easier to work with" but it would enlarge the scope to transforming non JSLON-LD JSON documents. I don't know why we should want this, we should make JSON-LD itself easy to use and flexible enough to be close to a domain specific format in many cases.

I don't think that this would address #146. A resolution of #146 would broaden the possible serializations of RDF Graphs into JSON-LD allowing JSON-LD to be more similar to a dedicated JSON format for some common use cases

[gkellogg]

I think it's confusing to talk about this as a "pre-processing step", and should just consider that there are additional expansion rules. We already have expansion, which is a necessary part of most API calls. What we've been calling "pre-processing" should instead be part of the expansion algorithm, which might not have a counterpart in the compaction algorithm.

[lanthaler]

RESOLVED: Do not support a pre-processing step option in the JSON-LD API to transform incoming JSON.