Hi,
First, let me appologize for my approximate english in the following post.
I discovered Anchor modeling by chance 2 years ago, while I was browsing the Internet looking for conceptual representation of data. I recently used your online modeler to put a new perspective on a data model.
While modeling, I stumbled upon a few conceptual problems that required some brainstorming on my own. I think it could be a good idea to share about what I did and why, and I hope to receive some reviews or commentaries.
All comments and remarks below only takes the conceptual level into consideration. I am not suficiently versed into databases to make assumptions on the physical level.
The first point I'd like to talk about concerns the rationalisation of the model when two or more anchors share similarities and have a common subset of attribbutes and ties. In other words, those anchors that are specifics derivating from a common and more general concept/anchor.
A good exemple would be to model the "administrative staff", "professors" and "students" of a school. Let all of them be "persons" and have names and emails, students also are in a promotion while "staff" (administrative staff and professors) have a salary. Furthermore, a professor has an experience level (junior/senior) while administrative staff have titles. Persons and staff are abstract concepts.
Here is an UML representation:
Hereafter are different approaches I considered (please note that the order of presentation is not insignificant).
First approach: multiple dissociated anchorsThe different concepts of student, professor and administrative staff may be considered as distinct and unrelated (but may be tied). In that case, the attributes and ties of the more general concepts are replicated to each specific anchors.
That approach is straightforward but I think it poses to much scalability problems: if we later add, for exemple, a birthdate to a person, it has to be replicated to every concerned anchors. We could also add an "External speaker" as a new kind of staff...
On the good side, I note that in this model we can set different historization and assertivity depending on the need (for exemple, we might want to historize the name of an internal staff member in case of change in marital status, while disregarding the historization for a student or external speaker).
In my point of view, having this kind of model is rather due to a conceptual error, highlighting a missing "super-concept".
Second approach: single anchorAnother easy way is to merge all specifics into one anchor. No problems here with duplication, but the difficulty resides afterward when one try to determine what "kind" of person is a particular instance: we need to check the attributes or ties to do so. Here, the problem of scalability has moved from the data model to the interpretation of the data. Also, with too many attributes and ties, the model lose its readability.
Third approach: single anchor with a knotted attributeVariation of the second approach with the addition of a knotted attribute to determine the "Kind" of a person: resolves the interpretation of the data but not the readability of the model.
Another good point is that we can have this attribute historized, effectively and easely modeling state changes / mutations.
Fourth approach: using ties to model generalizationHere I used the principe of generalization from UML into Anchor. The binary relationship of generalization is transformed into ties between "specific" and "general" anchors. For those like me used to UML modeling, it is quite simple to understand and I think it's compliant with the Anchor modeling objectives. It is scalable, rationalized and, to my opinion, much more readable.
Still, like the Second approach, searching what "kind" is a person needs to make many joins...
Fifth approach: using ties and knotted attributes to model generalizationNo need to explain...
Going past the consideration of which approach is better, I think the Generalization as used in UML can work in Anchor modeling as a part of it without major changes to the model mechanics.
Here is a suggestion for a representation using a new type of tie, please tell me what you think of it:
As a last note: I referred to UML in this post. I do think that Anchor modeling will gain more visibility and interoperability by having an official metamodel in UML (unless it is already the case but I only found a post about an Ecore-metamodel in Eclipse --> I admit I did not check what is this "Ecore-metamodel").
EDIT: the proposition above is just a general idea that needs to be elaborated, for exemple about historization, restatment, allowing or not multiple generalization (having more thant one "general" anchor for a "specific" anchor)...
