Re: The anatomy of plagiarism that was made by authors of "Anchor Modeling"

From: vldm10 <vldm10_at_yahoo.com>
Date: Thu, 23 Apr 2015 03:19:48 -0700 (PDT)
Message-ID: <98c112e3-6adb-4db2-af5e-74502015a3bb_at_googlegroups.com>

Considering that this is a database solution of great importance and that significantly changes the current theory of data bases, this plagiarism is very carefully worked out, and therefore it also took a long time for proper display of plagiarism.
My paper has been published in 2005, that is four to five years before the papers of the "Anchor Modeling", which were published in 2009 and 2010th. My paper, I explained in detail on this user group. From 2005 to 2015. I want to emphasize that there is a little scientific papers which have been so thoroughly explained and presented by an author.

1.
In this post I will present the anatomy of one more plagiarism, that authors of
"Anchor modeling" made. „Historized Attributes“ and time are important parts of
anchor modeling.

---

Their main data structure "Historized attribute", the authors of "Anchor Modeling" are defined as follows: Hatt (C, D, T). Here we have: C is a surrogate key of the entity, D is the attribute of the entity, T is time. For example, if a car had the blue color, and then the black color, then the following table represents history of color attribute, in anchor modeling:

Example1:

313   blue     2008-08-20
313   red      2009-11-09

...

In "Historized attribute" the authors of the anchor modeling introduced only DateFrom. This is because they believe that "DateTo" is equal to "next DateFrom".

--
And this is plagiarism of my paper. If you look at example2 (it's below) from my 
paper from 2005, then you may notice that for key = 117, we have DateTo = 28 / Oct / 
04. For key = 118 we have DateFrom = 28 / Oct / 04. So these two dates are the same. 
Here I actually used the construction, which makes DateTo same with the next 
DateFrom. Obviously this my design from 2005 was plagiarized from the author of 


"Anchor Modeling" in 2009.  



Note that Date3 and "next" Date4 in example2 do not have equal value. In short, in 
example2,  I gave solution for "bitemporal" data. Date of events in the real world is 
represented in one way - Date1 and Date2 are date from the real world events. 
The system's date (the date when the data had been entered in the database) are 
presented in a different way - Date3 and Date4 are system's date. With example2 I 
wanted to show  one solution that is more general. This matter is not "a must" as 
authors of anchor modeling proposed it and misunderstand it.
This my example2, can be understood, for example, as "data entry screen" or a derived 
relation. The intention here was to show that there is a more general approach to 
this issue.
I showed that if I want I can present the real world data in the different way than 
system's data.

Thus my solution can work as well as the solution that is plagiarized by the authors 
of "Anchor Modeling". Or my solution can work also as  time intervals. Thus, the 
authors of "Anchor Modeling" plagiarized just one special case of my solution for 
bitemporal data. Note that their solution can not work with time intervals, because 
6NF does not support time interval (in general case). Note that authors of „Anchor 
Modeling“ put 6NF in title of their

In fact I did not introduced bitemporal data in my papers. In contrast to anchor 
modeling, I have introduced a more general solution in my papers - this solution is 
n-temporal data.

In relation to the work with date, which are applied in "Historized Attributes", we 
can notice that when data-entry-person enters an incorrect date in Historized 
Attributes, then it will be created a mess in the Historized Attributes. Since 
Historized Attributes are the main data structures in "Anchor modeling" then it means 
that there will be chaos in the "Anchor Modeling".

Let me explain this in more details:


"Historized Attributes" have the following scheme: (surrogate-key, attribute, time). 


First, we can notice that in this scheme, there is no "metadata". All "metadata" are 
reduced to a "T".
In their paper "Analysis of normal forms for anchor-tables", these authors are 
proving that Historized attributes are in the 6NF, but proof was made without 
metadata. By the way, the most difficult part of the proof is "metadata". Example2 is 
just a small example about how much "metadata" can be complex. (see example2 later in 
this post).

The key is the part that authors of "Anchor modeling" changed in this plagiarism. The 
creation of this key belongs to the authors of "Anchor Modeling".
This key has the following scheme (surrogate-key, time), now we can imagine that the 
data-entry person enters the wrong time into database. Or that enters the wrong value 
for attribute. Or make a mistake for both - for attribute and for time (on purpose).
For example, if the error is made only in the attribute, then it is impossible to 
enter the correction, because we would get a double key. If one delete the wrong 
attribute, then there is no history. Longer analysis of this ad hoc case would show a 
real chaos in the db design using anchor modeling.
***********************************************************************

===============================================================
(This example is from 2005, see at my paper „Some ideas about a new data model“ at 
http://www.dbdesign10.com )

Example2:
The table Savings has only two attributes: Amount and AmountKey. The second attribute 
is the primary key. The table is simplified for the purpose paying attention to 
creating knowledge. Usually we create a table like this: 

(i) 
AmountKey      Amount 
---------------------------------- 
... 
116                    $2000.00 
... 

However if we want to implement knowledge on the level of a value of the attribute 
Amount, then we can, for example add six new columns in this table: Date1, Date2, 
Operater1, Date3, Date4, Operater2. Table Saving now can look like: 


AmountKey  Amount   Date1   Date2    Operator1      Date3       Date4   Operator2 
------------------------------------------------------------------------------------- 

... 
116    $2000.00  5/Oct/04    1                John Mayell     6/Oct/04    1              
Paul Jones 
117    $2000.00  5/Oct/04   28/Oct/04   Mick Smith     6/Oct/04  29/Oct/04   Lee 
Evans 
118    $2500.00  28/Oct/04   1               Mick Smith     29/Oct/)4    1              
Lee Evans 

End of the example2. 
==================================================================================
 
Example 2 shows that 6NF can not do the decomposition of data structures on atomic 
structure.
General db is totally contrary based of RM. In the RM, we have the following 
operations with the data: delete, add and update. In the General db we only add data. 
In the General DB we have redundancy. Moreover, redundancy is desirable in the 
General db in terms of preserving all that is done in the database; and that is the 
exact opposite of RM. The authors of "Anchor Modeling" it does not even realize. They 
put 6NF in the title of their award-winning paper from 2009. However, normal forms 
belong to RM. 

2.
Here I will give some examples which I think throwing more light on the anatomy  of 
the plagiarism that is presented in this thread. 
==================================================================
In thread „Full Name as Composite Attribute“ at this user group, in my post on 28 
March, 2005,  I wrote: Regarding the "Full Name" composite attribute, the situation 
can be more complex, because giving names can be a very complex procedure. Here is 
one example; we are supposed to create a DB with Donald Duck, Mickey Mouse and some 
other Walt Disney characters. We can put them into tables, create tables with them, 
create some of their
relationships, i.e. - we can create a Relational DB. But, although people know much 
about these characters, even their personalities, they are not from the real world; 
Walt Disney made them up. So, there is no Conceptual Model because there is no 
mapping from the real world for these full names. In fact Frege's theory about names 
can explain similar examples. I think that those members of this group who are good 
at Semantics and Mathematical Logic can give us more valuable comments about theory 
of names.“
--
In thread „the two questions at this user group, in my post on 28 November, 2007,  I 
wrote:
„Btw, can be many combinations and cases - databases with abstract entities (Donald 
Duck, Mickey Mouse, Pegasus...) All computers' games are not from real world, there 
are databases for future (an annual budget, for example), multimedia db, etc.“
--
In the above two post I wrote about databases with abstract objects. Now, on 
wikipedia I can find an example of ancor modeling database with abstract objects. The 
database contains the following abstract objects:

„An example of an anchor for the identities of the nephews of Donald Duck is a set of 
1-tuples:   {⟨#42⟩, ⟨#43⟩, ⟨#44⟩} “

( Look at the web address:  http://en.wikipedia.org/wiki/Anchor_Modeling  )

=================================================================
In my thread "The original version", at this user group, in my post on 28 December,
 2010,  I wrote:
„It is possible for two men to possess different values for a certain property, for 
the same period of time. Similarly, this can happen for a relationship. A manager 
wishes to record both of these values. He wants to maintain statistic of bad workers. 
He also wants online db.
The following case is for instance possible in court: One side claims the car in an 
accident was blue, the other claims it was red, while the police claims the car was 
black. The court requests that all of these three colors be recorded in the database. 
Obviously, Anchor Modeling cannot solve this.“
-----------------------------------------------------------
At anchor modeling website: 
 http://www.anchormodeling.com/wp-content/uploads/2011/05/Back-to-the-Moment.pdf  
there is the following text (from 2013):

„It is about concurrency
•Even if A and B disagree, say on a value for a property, such that: 
A uttered “Leonardo’s hair was brown.” 
B uttered “Leonardo’s hair was blonde.” 
both views can be recorded, resulting in 
a concurrent-temporal implementation“
-------------------------------------------------------------------------------------
---------------
As I wrote in my thread, anchor modeling canot solve the above problem. Here is my 
explanation: „Historized Attribute“ has the following form (surrogate key, attribute, 
time) and 
Key = (surrogate key, time)
Obviously, „Historited Attribute“ will have the duplicate key for the above two 
attributes – brown and blonde. Note that my solution can support this case. 
==================================================================
I would like to mention that there are several theories about the time. We are 
talking about the application of time in the databese theory. When it comes to 
applying time in databases, then usually there are two theories.
The first theory proposes that time is continuous. 
The second theory proposes that time is not continuous, that is there is quantum of 
time. The name of this quantum is Chronon.
Both theories are based on hypotheses, there are not proved. My data model can
 support both hypotheses. 


Vladimir Odrljin

Received on Thu Apr 23 2015 - 12:19:48 CEST