Functions attached to concepts example
Sure! Give me a minute, I'm trying to cook up an example where this situation naturally applies so that we can look at an example of something that isn't contrived just for the sake of demonstrating this need
7 Replies
Idm starting with whatever situation made you feel like you needed this. If it's too contrived then you can simplify it 😅
so here's what I think is the contrived example, attached as a photo because I can't figure out how to model it well in TypeDB. "antibody" is the type, which acts kind of like a schema in the sense that anything that's an instance needs to fit this pattern of binding some antigen, but also like data in the sense that there's an interaction between every antibody and complement (I named this interaction "binds", but this is distinct from the type of binding that's going on between antibodies and antigens - that's on me).
I'll follow up with a second example that I think led me to try to represent this with a function rather than just an instanceof relation:
Coming back to rules real quick: in 2.x rules meant that it was easy to "instantiate" the antibody -> complement relationship on every instance of antibody automatically, but I think I've moved on a little from this approach - there's a lot of semantic clarity that I get from having the arrow go from the broader type to complement
Here's the second example:
SERM is the overall type, defined by a drug's mixed interactions (inhibition and activation) with the different E_ receptors. Sure, we can define "SERM" as a type in the schema and then define tamoxifen and raloxifene as data in the SERM type, but turns up some drugs that weren't originally created as SERMs have mixed activity at E_ receptors that is later discovered, and these two facts together would mean having to go back into the database schema/data write phase to fix the type hierarchy. Hence the desire to represent "SERM" as an entity that can find all of its members based off the relationships they have to E_ receptors.
Why would you have to change your schema when the discoveries are added? What other types can drugs be created as?
I don't know whether the best way to talk about this is to stick to your domain or try to paraphrase it to check my understanding of the problem.
It looks like a drug is a SERM if it satisfies some sort of functional characteristic (interacts with E_?) Maybe SERM should not actually a type of entity, but a type of relation or role?
The analogy would be that I (inserted as a person) would be an employee if it were discovered that I interact with (work for) a company?
In our examples, we typically model the employment as a relation, rather than turning me into an instance of type employee (interface polymorphism v/s inheritance polymorphism).
Does the same apply to SERMs? If not, what does this approach miss?
That's a good point, I will try to paraphrase some of these out of the domain-specific language.
I think I'm realizing my instinct about when to represent something as an entity versus a relation needs to be calibrated. Will need to mull over this for a bit. My gut feeling is that we're still missing something, but I need to test this out independently to be sure and come back with further questions
I'm a TypeDB newbie, but architecturally, it sounds like you might be describing a job for the Strategy design pattern.
https://en.wikipedia.org/wiki/Strategy_pattern
Concepts could have an attribute (or relationship) that specified the instance-specific strategy to use. Strategies themselves could be instances of a Strategy entity type if you want to maintain type safety.
Strategy pattern
In computer programming, the strategy pattern (also known as the policy pattern) is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives runtime instructions as to which in a family of algorithms to use.
Strategy lets the algorithm vary independent...