Implement resource attribute extensions in observation DNA records

[pospi]

Following https://github.com/BeefLedger/multiplatform-poc/issues/112, need to take the industry standard resource data schema and implement extensions to standard Holo-REA modules to carry the extra data.

[fosterlynn]

Do you have a sense of how you want to implement extensions? I assume they will be optional for other people implementing Observation DNA? Do we know enough from this one user to start a beef industry standard? (I think maybe we don't, from looking around online a bit, but I don't really know.)

[pospi]

Now that everything has been more cleanly modularised, it's starting to look fairly simple. I have already laid out the necessary scaffolding. One essentially has to do the following (which is actually a good work breakdown to use when implementing this):

• Extend the EconomicResource zome by:
  • Adding additional Holochain entry defs to store the struct data for the additional attributes
  • Managing links between the core REA storage data structures and the additional attribute storage data structures such that they can be retrieved in reads efficiently
  • Changing the call signature of get_resource, query_resources and update_resource to return a different data structure which includes the additional parameters
  • Binding the new response structure to the core hc_zome_rea_economic_resource_storage structs & fields in addition to the new struct data; such that if the Holo-REA platform is updated and attributes have changed, the compiler will complain until the third-party app developer updates them
• Do all of the above again for new_inventoried_resource in create_event.

To answer your question: yes, it is certainly optional! In fact as we're working through the process of integrating an RFID scanner with the observation DNA we're finding there isn't much there that could not be handled by core VF anyway. So the beef industry thing may not be the example that ends up getting used to illustrate this.

In answer to your other question: the most certainty I could give presently is that these are RFID tags that are placed on all boxed raw cut beef exported from Australia to China. The standard may go broader than that, but if it does I haven't explicitly confirmed that.

[pospi]

Oh, and the script above applies in a similar but less complicated way to anyone wishing to extend any part of the system now. You will note that the other folders in that directory (fulfillment, satisfaction & eg. process) only have an .hcbuild file in their zome directory, which points to a WASM build artifact generated by the core Holo-REA build process. This is how you can easily extend and customise parts of a DNA with additional zome logic whilst using other zomes in their unaltered form.

[fosterlynn]

integrating an RFID scanner with the observation DNA

You are using trackingIdentifier to hold the RFID?

we're finding there isn't much there that could not be handled by core VF anyway

That's nice to hear. How are you thinking to handle breed etc?

[pospi]

Yes to trackingIdentifier.

Breed etc I see as being type-level, not instance-level. So those things will probably end up being done as ResourceSpecification customisation case studies that show how to build domain-specific knowledge systems.

Anyway, parking this issue now as we as yet have no customisations we need to make.