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.
Uploaded images can be several MB in size. While offering the big size
would enable other apps to resize it and store the image size they need,
we have only one app using it in practice and it's using the image
directly. It's much simpler and if a default size will work for others
in the future then why not just serve that.
We can revise this in the future. There is a DFC discussion about
publishing several sizes which I started:
https://github.com/datafoodconsortium/ontology/discussions/77#discussioncomment-8228094
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.
Add our own address to include `region`, currently not supported
by the DFC connector.
`region` is already included in the next branch of data-model-uml:
729eba31a5
To me removed once the DFC connector is updated
Update pending payment for cash order, so we can take into account any
changes affecting order toral (shipments, line item quantity etc...).
This is to allow payment capture to cover the order total, not just
the amount due at checkout.
We want to use this image in the Discover Regenerative portal in
Australia. The property is read-only and the API doesn't support the
upload of a new file.
The enterprise factory needed fixing as well. This trait hadn't been
used anywhere else.
The `dfc-b:hasType` value can only be parsed as object id if the context
contains:
```
"dfc-b:hasType":{
"@type":"@id"
},
```
The standard context includes this and it's easier to use. Now that the
URIs of product types are correctly resolved, we don't need to
substitute the URI manually.
Also dropped an old unneeded spec for backwards compatibility.
The given productType.rdf file doesn't give us any context for `dfc-pt`,
so there was no reason to do that.
We still need to do some substitution in the importer, as some times
we are given `dfc-pt` as input data.
