feat: Create RepresentationConverter that chains other converters

[joachimvh]

So I changed my mind and did make some sort of meta converter. This one is still sort of simple since you have to define what the intermadiate types are going to be (otherwise I would have to think about the best interface changes to request this information from the converters), but in practice this is going to cover most cases I think.

Haven't actually tested it with real converters yet, wanted to first check out the other PR with the new converter for that.

[rubensworks]

This one is still sort of simple since you have to define what the intermadiate types are going to be (otherwise I would have to think about the best interface changes to request this information from the converters

It's a bit unfortunate that we have to define types manually in the config with this.

How much effort do you think it would be change these interfaces? Maybe it's not that much work?

[joachimvh]

How much effort do you think it would be change these interfaces? Maybe it's not that much work?

Well depends on how far you want to go, I was thinking of just having a getter for the supported input/output types, but then perhaps you could have some converters that can't go from all their supported inputs to all their supported output.

Perhaps also some of their output types are more expensive to convert to if they have multiple, which you can avoid with the manual case (or extending the interface mentioned above with some weights, but you can see how you can keep thinking of more cases).

But these are potentially all edge cases and I could ignore them and add a simple getter interface.

[rubensworks]

I was thinking of just having a getter for the supported input/output types, but then perhaps you could have some converters that can't go from all their supported inputs to all their supported output.

In Comunica, parsers and serializers must expose a hash that maps content types to priorities. AFAICS, something like this should cover most cases.

The recently added generic parser and serializer expose this information as well, so you'd get that for free with them.

[RubenVerborgh]

Nice.

[joachimvh]

The ChainedConverter now dynamically determines the "path" that needs to be taken. Slight performance hit (although this is probably quite small compared to the actual conversion), but more dynamic.

If you're wondering why I created TypedRepresentationConverter instead of just adding the functions to RepresentationConverter, the reason is that otherwise we wouldn't be able to use a CompositeAsyncHandler anymore for that type.

[rubensworks]

Might be good to document here that this priority number should be a value between 0 and 1.

[joachimvh]

True, will change

[rubensworks]

Looks great!

Is there anything that blocks us from wiring this up in the config already?

[joachimvh]

Is there anything that blocks us from wiring this up in the config already?

Nothing, except that I didn't really test this yet on an actual case because I first wanted to get the interface right.

[joachimvh]

I'll look into writing a small integration test for this and then adding it to the config.

[RubenVerborgh]

Great work!!

[joachimvh]

Can confirm that with the default config you can now PUT a turtle file to the store and then GET JSON-LD.