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.
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.
