Roberto Guido

I would like to implement this, but I'm unsure about the approach. - expose a `TypeMapper::guesser($type, $callable)` method, to specify an arbitrary function which retrieves the desidered type given the...

@zozlak - why attach a TypeMapper to each Graph? Actually it is global, one for all, you can init it as you prefer once and still - if you really...

Seems fine. But out of the scope of this issue, which is all about introducing a brand new type of mapping strategy (along the existing one, RDFtype-based).

Probably I choose the wrong terms, and "mapping strategy" was not the right one. Graph needs some way to obtain, from TypeMapper, an information: which is the PHP class to...

Some time ago I've implemented this simple package wrapping a Guzzle HTTP Client into EasyRdf\Http\Client https://gitlab.com/madbob/easyrdf-on-guzzle Probably this can be considered as a placeholder until actual integration of PSR-7 into...

I'm getting a look into this, but I must confess it is a bit complex to keep everything functional also with Http\Client and Zend\Http\Client. There is an high chance to...

The purpose of adopting PSR is exactly to *not* have your own HTTP client, but use those existing (and interchangeable). Eventually we can provide a default: [nyholm/psr7](https://packagist.org/packages/nyholm/psr7) seems to be...

Pull request #381 (I'm intercepting add() and deleteSingleProperty() calls to keep track of modifications operated directly into the Graph and provide further elaborations).

This would become obsolete after closing #133, due middlewares pluggable into the PSR-18 HTTP client provided by the implementing user.

Mostly handled by PR https://github.com/easyrdf/easyrdf/pull/379, as the PSR HTTP client provided by implementor can be configured with desidered behaviour (handle as many redirects as required, or just fail when a...