Early versions of the DFC standard demanded that all data is published
in relationship to the authenticated user. But that is not necessary
anymore and can add complications when a platform is authenticated as
client user.
There will be lots and lots. The sales data root object is also the
authenticated person. The data has its own URL (semantic id) which
doens't need to contain the user id.
The service object can also be tested more easily. I'm setting up the
test data here.
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
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.
A DFC SuppliedProduct relates to a Spree::Variant and when updating its
name we only want to change the name for that variant. Otherwise, when
we update the name of the product, it would update the name for all
variants and all the corresponding SuppliedProducts.
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.
