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).
The DFC Prototype does include the context while the output of the DFC
Connector refers to the URL of the published context. While that's more
efficient, it's also brittle because the context is updated from time to
time. That happened three days ago and working with the newly published
context breaks our integration until we get an updated version of the
DFC Connector containing the new URLs for datatypes.
This allows us to run the specs separately to generate the
documentation. It's more efficient this way and the separate swagger doc
file is easier to read.
The engine-specific swagger helper also allows us to simplify the spec
files.
Added an exception to our styleguide because it's intended and useful to
have a complete (lengthy) description of the API in one block.
In other API specs, you provide example values in the schema. So the
specs contain examples which can be used for the documentation. But
instead of defining example data separately, we can use the generated
data by the specs. This way we document real output and don't have to
double up on documentation.
Note that we don't have schema definitions for the DFC API yet. And it
wouldn't make sense to replicate the DFC Ontology manually in JSON
Schema for this purpose. The DFC Connector ensures already that we
comply with the ontology. But I hope that we can use a tool at some
point to generate JSON Schema from the DFC Ontology which would add more
detail to the Swagger docs, I think.
