discuss motivation / strategy behind the __call__ usage inside config_builder

[marc-portier]

not quite self-explaining at the moment

also unclear what the current benefit is

it feels like we could get maybe use it to "activate" some of these objects (i.e. make the transition from pure passive configs to objects that also use access to rdf_store to make some active decisions

regardless that last part, if we keep the _call strategy around, we should at least opt for some naming convention that makes this less surprising (or rock bottom: make sure we have good docs for this part of the (mostly internal) API / usage)

[marc-portier]

when reconsidering the way we handle the config (also see #44 #35 #48) we should reconsider the way property paths are handled

the current regex

py-trav-harv/travharv/config_build.py

Line 190 in bac4fe2

REGEXP = r"(?:\w+:\w+|<[^>]+>)"

simply cannot be checking for / delimitors, meaning it will behave similarly for any other (or even no) delimitor between the parts -- which I assume is not what we want?

the recent code sample added in #35 (comment) contains an alternative approach --> adding a slash to the string to match as well as to the regex pattern (with optional whitespace) keeps the pattern fairly simple + guarantees the delimitor