The Spree::Variant in OFN corresponds to a DFC SuppliedProduct. But
several Spree::Variant can be grouped under one Spree::Product which
wasn't exposed on the DFC API.
I'm adding a custom property here which can be used internally and
shouldn't break any other DFC tools.
A gotcha of this first test implementation:
The `ofn:` prefix has not been defined in the context. Software needs
to know that this is an Open Food Network attribute or ignore it.
We could define our own context and ontology and publish it on our
website but I don't see any benefit of that at this point.
The DFC doesn't actually specify which cup it means. I don't expect
anyone providing "cup" as unit to measure their produce and expect it to
calculate as a regular volume. It can just be seen as items.
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
I observed new data from the DFC Prototype. It now uses the DFC 1.8
ontology with the hasQuantity object.
It now also uses PUT requests for updates because PATCH is not as well
supported. Rails doesn't care though.
I couldn't observe a request for the CatalogItem yet because the
Prototype failed to send it.
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.
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).
