The new DFC Connector is based on the new DFC context which changed all
URLs of all data types.
There's also a better way to access semantic properties now.
This protects us from the DFC website going down or the DFC updating
the context with breaking changes. We are in control of updating the
context now (opt-in to newer versions).
OFN products and variants need more data like a price but the DFC
stores that in a different object. We may get a larger graph containing
that information but we don't have any test data yet.
This is work in progress. The DFC Connector uses a more recent DFC
version and other endpoints still use the old serializers. We need to
update those endpoints as well and update the version number in the API
URL.
Services are usually not namespaced because they are part of the app.
This engine has an isolated namespace which means that we don't need to
separate with out own namespacing here.
As explained in 36c44a5487, it's not normally good to change production code to make testing easier.
But this tiny change makes it more robust, and enables much simpler specs.
We were just logging in any user without password or other verification
before. Now we verify the Keycloak signature and know that the person is
indeed logged in.
This one is a bit confusing. The attribute changes throughout the
different versions of the ontology and the DFC examples are not in line
with the specification. WIP I guess.
The previous nil attribute failed JSON-LD validation and DFC examples
just contain the reference as I did it now. But I think that we will
need to update it again vor DFC-v1.7.
And let the OFN app decide under which name to mount the DFC engine.
It simplifies the code and will make it more flexible to introduce other
versions in the future.
I want to add other ways to authenticate for easier testing and possibly
more integrations. It will be easier to just test if we got a user or
not instead of testing pre-conditions to that as well.
