decide on decorator strategy for dealing with cleaner and mapper

[marc-portier]

          > Will the clean method be a separate decorator function or will it be included by default in the insert method of the decorator?

the self.clean is a method on the base-class already -- see https://github.com/vliz-be-opsci/py-RDF-store/blob/c9f5b9cb1b295b19576f73b8960b7b5ae2e40ee6/pyrdfstore/store.py#L105

so the decorator actually inherits that automatically but I currently don't activate that (no constructor args for cleaner and mapper, and no passing them to super().__init__)

I have not done this mainly because the decorator also embeds a _core member that already does its own cleaning, and I don´t think we need anything more on the decorator levels

To be honest I have not yet decided how to deal with letting decorators "add" cleaning steps as part of their decorating work in theory it should be just a matter of overriding the methods and have them call their own graph = self.clean(graph) before delegating to super().insert(graph)

Similarly the name-mapping features should be considered in that exercise -- but honestly, they even seem less useful to foresee on the decorator level.

So probably leaving this topic to post 0.0.2

Originally posted by @marc-portier in https://github.com/vliz-be-opsci/py-RDF-store/issues/49#issuecomment-2056376944

[marc-portier]

thinking about this some more -- and getting closer to "we don´t need it"

@cedricdcc , @bulricht , @laurianvm -- will close this as wontfix if none of you come with a practical usecase or other motivation