Holochain Forum

Holochain & Conceptual Modeling « Killer-Features »

In the context of the SEAMLESS initiative (https://github.com/iPlumb3r/SEAMLESS) we know that we are going to deal with 3 mains kinds of features (namely « killer-features ») …

Those features are

  • Multi-Typing
  • Link Reification
  • Meta-Modeling

A GitHub page for those features is available here : https://github.com/iPlumb3r/KeQuarks/blob/master/Features/Killer-Features_EN.md

This page is linked with a specific page for each feature

@Pospi already answered for Multi-Typing …
… but I wonder now, what about for the 2 others features with Holochian / Rust ?

Best Regards

Bernard

1 Like

Hi Berndard! Nice to hear from you :slight_smile:

So, let me see… “link reification” being an ability to describe graph-like data structures in applications? If I got that right, then yes. Holochain has an EAV in addition to its CAS.

Muti-typing sounds more like a ValueFlows DDD thing, in terms of the use of “type objects” to provide foundations for an indexable web of information attached to resource & process types.

And meta-modelling- you’ll have to unpack that for me but it sounds… ambitious? Like the kind of thing that would require a lot of participation and a lot of data to work well. Otherwise to me with ValueFlows that’s primarily about how we represent flows to people, in order for them to author recipes, deploy plans for action from those blueprints and watch those actions unfold in real time. It ends up looking a lot like petri nets in chemistry (see link).

1 Like

Thanks @pospi for reply.
Here after some more precision …

LINK REIFICATION

The idea behind the term « Reification » is « makes a link between two entities also an entity »
(So you can do to this link everything you can do to an entity, just because it is also an entity)

More input about this feature here : https://github.com/iPlumb3r/KeQuarks/blob/master/Features/LinkReification_EN.md

The basic use case is described in the section « Smooth evolution of the model : »

Example :
If the entity is « Tim Berner Lee »
And the attribute is « affiliated to »
And the value is « W3C »

How did you state that the « hiring date » of « TBL » at « W3C » is « 01/10/1994 » ?
(Where this information is semantically speaking carried by the « affiliated to » link between TBL & W3C)

Can you make a « Smooth evolution of the model » (i.e. without « breaking » the 1st one) … … in order to record this kind of information ?

MULTI-TYPING

The idea behind « Multi-Typing » is to have entity that can inherit from attributes defined in 2 (or several) classe(s)/type(s)
e.g.
If the entity « myDesignedScrew » belong both to the types « designedThing » and « screw »,
This entity will inherit of :

  • the attribute « designed » (from the « designedThing » type)
  • the attribute « length » (from the « screw » type)

Is this feature supported by Holochain/Rust ?

META-MODELING

Yep, It could be see as an ambitious feature …
… but it some context it is really necessary in order to maintain a strong coherency between several abstraction layers

For example, in the use case described at the end this page : https://github.com/iPlumb3r/KeQuarks/blob/master/Features/Meta-Modeling_EN.md
You can see that the entity « product » is both

  • an instance/individual in the M2 context/level (instance of « Business Subject » defined in the M1 level)
  • an class/type in the M3 context/level (type of « car », bus » & « truck »)

This is very close of what you described in this diagram : https://speakerdeck.com/mikorizal/everything-in-valueflows-is-connected?slide=2
Entities of the « Observation » level are instance of entities of the « Knowledge level » … … which are instance of entities of - the non-represented - « entreprise architecture » level

If it is not supported directly, perhaps there is a way to maintain this coherency ?

1 Like

Hi - am checking in on the latest holochain goings on and saw this conversation, have not seen SEAMLESS before, it looks very interesting!

I note the comment re meta modelling being ambitious and it reminded me of my other most favourite project apart from Holochain which is Pierre Levy’s IEML - Information Economy Meta Language. It’s attempting an even wider scale than business models but may provide some insight into approach of these issues:

Hi @stevepurkiss

Yep, SEAMLESS try to define the « ingredients » and the “recipe” for building fully distributed semantic-driven business applications …
… and in this « quest » its appears some questions about features of (meta-)models !

I have IEML in my « radar » : https://www.topincs.com/EntangledBootstrap/2006
… but I must admit it is not easy to deep dive into such an approach.

As you could see I consider it as a possible solution for identifying Concepts in the context of the distributed web
(Versus some others solutions)
See : https://github.com/iPlumb3r/KeQuarks/issues/2

But for now I’m not able to say what is the « best » solution :wink:
Thoughts ?

Best Regards

1 Like

Ah the old “best” chestnut :wink:

Without knowing much about the goals and scope of your project, my initial thoughts are if you did plug into the IEML philosophy that would enable an extra layer of calculation and interactivity between models and of course any other IEML based project, however as with all these projects the success depends on adoption.

On one hand if you have an easy to use identifier it means you don’t have to sell/explain another system like IEML however on the other it does provide a potentially unique advantage over anyone else creating a similar system to yourself as I am sure there will be.

I pointed Pierre to Holochain saying it could be the perfect system for IEML adoption as I believe the nature of the two fit together well so it would be good to explore, however I also realise I live in a Utopia where I don’t have to sell this idea/concept, in reality it seems the “best” technology is not necessarily the one that gets adopted.

Sorry I can’t answer your question more specifically!

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?

Links

So about links… Links in holochain are already their own entries, stored as a standalone entry in the DHT you can do get_entry queries to them, and I even think you can link them to other entries, though I haven’t tried.

Right now you can only link from/to statically known types, but in the future this will most likely change to allow much more flexible possibilities.

In any case, I think you’d want to create holochain’s own links to be able to know which links are attached to the entries, otherwise if it’s only another entry in the DHT there is no way to find them…

If what you want to achieve is bidireccional links having the two links (from A to B and from B to A) created seems to me like the optimal solution in terms of DHT load and performance.

Multityping

Here I’'m just going to offer Cortex (What is Cortex?) as an alternative to dynamically recognize objects and add behaviour to them, based on patterns. Maybe this will prove useful, maybe it won’t :slight_smile:

Huh, has that changed or always been the case? So just to clarify what you’re saying at a low level:

  • hdk::api::link_entries actually creates an entry to represent the link, and then wires up some data in the EAV store to associate it with the origin/destination link targets. The address of the link entry is returned.
  • Calling hdk::api::get_entry with such a link entry address will return the link itself… in Holochain’s internal link data format?
  • Calling hdk::api::get_links with the origin link target address internally follows the EAV to locate all link entries that have been created via hdk::api::link_entries starting at that origin.

Is that right?

Yes that’s right! I think this was always the case yes. You can see the internals working on the playground: https://holochain-open-dev.github.io/holochain-playground/; create an entry and a link in the technical mode and see where that is stored in the source chain and across the DHT.

Neat! Well OK then @hubject it looks like link reification is built into the core design (:

Hey, this is a really good news !
Thanks very much @pospi & @guillemcordoba for your investigations & complementary informations !

For those interested in the Ecosystem Mapping knowledge domain, here after some inputs regarding “business justification” for multi-typing feature : https://github.com/iPlumb3r/EcosystemMapping/blob/master/1_Semantic/About_Intentional_VS_Extensional_Dichotomy_EN.md

And also : https://github.com/iPlumb3r/EcosystemMapping/blob/master/0_UseCases/Bob_develops_SmartphoneCase_EN.md