refactor common functions graph_name_to_uri

[cedricdcc]

MPO

it is entirely unclear what is the semantics and expected use of these two convertor methods is (I mean: I need to check up on the implemementation to realise)

maybe take some inspiration from: https://github.com/vliz-be-opsci/py-sync-fs-triples/blob/main/syncfstriples/service.py#L25

that also allows for having a base to be injected

make sure you have clear semantics separating the two worlds you are converting between

on the one hand you need a ng == named graph (uri) to be used in the rdf_store api
on the other hand I think you have some trav-harv name/identifier thingy that comes from the config? task-context?

so maybe name things GraphTaskNameMapper with ng_to_taskname(ng) versus taskname_to_ng(taskname)

[marc-portier]

here is an obvious element of the confusion:

• at call side a config_name --> https://github.com/vliz-be-opsci/py-trav-harv/blob/1350bedcb7fb487ae754c949c37375ddc5e96228/travharv/trav_harv_executer.py#L68
• suddenly turns into graph_name --> https://github.com/vliz-be-opsci/py-trav-harv/blob/1350bedcb7fb487ae754c949c37375ddc5e96228/travharv/subj_prop_path_assertion.py#L27

while nothing changes... making an equivalence between graph_name and config_name that is not at all obvious

given the fact that named_graphs are a concept in rdf, and expected to be uri, I would have thought graph_names are depicting those, and are thus similarly uri already -- hence the remaining confusion that those would need a mapping to from uri

this is how inconsistent variable naming suggests a type-conversion that is not there

the only way for a fellow dev to know is to precisely discover this point of maskerading