Mateusz Żółtak

For me it looks an elegant solution would be to: * Allow to set default TypeMapper class on a Graph (while looking into the EasyRdf code I can only see...

> why attach a TypeMapper to each Graph To make it even more flexbile and cleaner (once we decided to make it more flexible than it's now). * In my...

My point is it rather does't make sense to hardcode another type mapping strategy into the EasyRdf. I think it would be better to modify EasyRdf in a way anyone...

Ok. Just your code examples were focused on implementations and not on defining an API :-) When it comes to the API I think my proposal of: ```php interface EasyRdf\TypeMapperInterface...

Than: * current `EasyRdf\TypeMapper` would need to get the compatible `getClass()` method with the type mapping code moved from `EasyRdf\Graph::classForResource()`: ```php public static function getClass(string $uri, array $properties) { $rdfType...

Yep, I'm aware of the workarounds (was able to find them during four years :smile: ), just I find the current behaviour so highly undesirable that I won't go back...

It affects all getters (`getResource()`, `getLiteral()`, `get()`, `allResources()`, `allLiterals()` and `all()`) both on `Resource` and `Graph` class. The `__get()` magic on `Resource` is affected as well. ```php $g = new...

I think it's the only option.

From the turtle format point of view it is as follows. The 2nd note in https://www.w3.org/TR/turtle/#h3_sec-iri states > Prefixed names are a superset of XML QNames. They differ in that...

> @k00ni I would love to but it seems to have too many changes since 1.1.1 I would say you give it a chance. It doesn't seem @k00ni introduced any...