The current implementation of the FDC is not adhering to the DFC
standard. The difference is added in this compatibility layer.
This should be temporary code. The FDC dev team should change their API
in their next development cycle.
Failing in this case may be desired in some circumstances but most of
the time we want compatibility and easy interoperability even when not
all data matches.
It relies on having dfc_name populated on the given taxon.
Matching is as follow:
- parse the DFC product types and store in PRODUCT_TYPES if needed
- match the dfc_name against PRODUCT_TYPES
- call the method returned on the DFC connector
Currently anything but the leaf level is modelled as a
DataFoodConsortium::Connector::SKOSInstance, which isn't supported
by the connector as "hasType" for a product. The lead level is modelled
by DataFoodConsortium::Connector::SKOSConcept which is supported by
connector. On top of is `#narrowers`, `#broaders`and `#prefLabels`
aren't set making it very difficult to travers the Product Type tree.
When the application is not preloaded then running Rspec doesn't know
Rails until the spec helper is loaded. So we can't use Rails to find the
path of the spec helper. This has been fixed before but the DFC Address
code was developed at the same time and missed.
We were aiming to use stable URLs to identify resources but the URL
helpers were still using dfc-v1.7 because that was the last and
overriding path of the mounted DFC Provider engine.
Using Spring was hiding an loading error. When you start Rspec, Rails
and its engines are not loaded yet. So our way to load the spec helper
via `Rails.root` did not work when you ran specs on their own without
loading Rails with Spring first.
We still have the scale stored in two places but in our current system
that's part of a unit's "id".
If the DFC adds that value to its standard then we can use it for lookup
and don't need to repeat it.
* https://github.com/datafoodconsortium/taxonomies/issues/7
We wanted to use our own context before but now I found a better way for
the connector to cache the context and therfore we can use the original
implementation again.
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).
