Thanks for further clarification @hubject!
Link reification
Hmm, this is going to be an interesting deliberation of semantics. I would say that Holochain doesn’t support this natively, but that we have made it support it. @artbrock & @zippy might have more insight as to what will be possible in future— Holochain “links” were previously described as a special case of “object attribute” so the question becomes whether it will one day be possible to declare attributes on attributes.
The versions possible with what we have currently though are “link naming conventions” and “entries as links”. Naming conventions is just about suffixing link tags- given your example, you might use the internal link names affiliated_to and affiliated_to_hiring_date which point from Tim to W3C and 01/10/94, respectively.
“Entries as links” looks like REA’s “joining records”, where you simply use an entry to store the link between two other entries and use multiple links between them all (in the case of the linked code there is a link between the entry and the Intent it publishes, as well as the Proposal it is published_in).
Now— are either of these real link reification? Given that the internals of a Holochain DNA are not accessible to the outside world except over its RPC interface, my opinion is “yes, in all the ways that matter”. There is more on this perspective outlined here.
But is it as simple as declaring a link and some attributes using some native syntax for describing links and attributes? No. It’s a translation between Holochain’s storage primitives and the functionality we want.
i.e. without « breaking » the 1st one
I suppose you would have to plan ahead to know which links will need to be implemented as “entries as links”, so not in that pattern. With “link naming conventions” you could do so but obviously that data is a bit loosely organised (requires coordinating a lot of related identifiers).
Worth mentioning that Holochain DNAs are static artifacts which can’t be changed after deploying. So any changes to a model would require a migration step, really.
Perhaps @guillemcordoba has more, I’m pretty sure he’s the one who has been building a Holochain playground app that lets you dynamically define links, entry structures etc.
Multi typing
Hmm, that feels like an outdated OO pattern to me. Rust does not support inheritance of any sort, so the way to do it would be through object composition & a little field translation at the API boundary. (See Favour Composition over Inheritance if you’re wondering why I say this is outdated.)
Actually the way you have described attribute inheritance above would be more akin to traits / mixins / composition (all similar, just different terminology in different languages).
Meta-modelling
Again, not supported directly but I think the actual implementation is pretty simple- it’s just about relationships between records and a calling context which decides which relationship is important.
@bhaugen sent me a most excellent article on object / type modelling architectures but I can’t track it down. I do have some stuff he sent me from a book that may be useful, though. Don’t suppose you can remember and share the article here, Bob?
