Considering I had free time during the holidays I could intensively
post new entries on the thread. Because work is beginning again, I
will limit my entries to a minimum. With this post I would like to
summarize what I have written so far:

1. This thread began because the authors of Anchor Modeling used a
procedure which I described on this thread in a post from May 26,
2010. I labeled this procedure "(a)" and I published this procedure in
2005. Procedure (a) and the basic idea of my work I stated in 2005 on
this user group, and Anchor modeling was released on November 2009.
Without procedure (a), Anchor Modeling is essentially worthless.
To conclude, the ideas of my paper were described and analyzed in
detail through specific examples to a broad group of readers.

2. I showed that though procedure (a) is important, it could not be
solution for databases.

3 I argued that Anchor Modeling can not even solve some major areas
related to "history" of the database. ( Erroneous data, relationships,
the deleting of data, non-sequential states, anomalies with "surrogate
key")

Unfortunately defending my work, I lost all my free time to work on
perfecting my paper.
In the end, I apologize to those who find this thread foreign, unusual
and monotonous.

Vladimir Odrljin

I received an email from Lars Ronnback, one of the Anchor Modeling
authors on August 25, 2010.
Among other things he explained to me that he and the other authors
have not read my paper. (“Unfortunately we have not read yours. Have
you got a URL to where we might find it?”)

Previously, I had posted the website addresses that contained my
papers from 2005 and 2008, but I suppose Mr. Ronnback wanted to know
the “URL” of a journal in which my paper was published. This leads to
the conclusion that:
1) Mr. Ronnback of Anchor modeling maybe thinks that papers from web
sites and user groups do not have any rights.
2) That things are not as I present them.

So I decided to post this text, though I had not intended to.
I submitted my paper on August 21, 2008 in Journal of Computing and
Information Technology (from Croatia). Croatia is a country of my
origin.
Almost a year went by after the paper was submitted without any
information about whether the paper had been accepted or rejected. I
realized that the paper could not be published even after a year, I
contacted the Editor-in-Chief S. Lonacaric and informed him I would
publish the paper on my website, and in the case that it was accepted,
I would give all the rights to his journal. I quickly received a
message from D. Mladenic (from Slovenia ), the Associate Editor, that
my paper was rejected. I inquired about the reviewers and got the
answer that I could not get reviewers names nor contact them. So if
one is interested in my paper, she/he can contact above mentioned
editors.

The only comment D. Mladenic made that was targeted at a specific part
of my paper was absurd. Here, the reviewer questions my employing the
same example twice, though these are actually two different examples;
see in the reviewer comment: “…instead of using practically the same
example more than once (see subsections 3.7 and 3.8)…”

I complained because in my opinion this paper was rejected without any
scientific arguments. My complaint was refused.
Then suddenly, quite by accident, I came upon the paper Anchor
Modeling. I wrote to the chief editor, S. Loncaric and stated that
Anchor Modeling was only a special case of my paper. I wrote that it
had received an award for the best paper of 2009 at ER Congress. I
also wrote that Anchor Modelling employs my ideas from my paper
published in 2005.

S. Loncaric has never responded to my note. As I mentioned S. Loncaric
is Editor-in-Chief in this journal.

I have since given up on publishing this paper in a journal, and have
published the submitted version online.
As far as I know, the aforementioned editors are not experts in
databases. According to their CV's, research by D. Mladenic is
connected to "Machine Learning, Text meaning", and the research by S.
Loncaric is connected to "Imaging".
All my life I work with databases, I was project leader on several
very complex projects.
At that point I began this thread. In my opinion the results of my
paper are important.

So, I put the main idea from the paper on web and on this user group
on September, 2005. I submitted my paper on August 21, 2008;
published the submitted version on my web site on March 7, 2009.
Anchor Modeling got award as the best paper on November, 2009.

I think this thread provides some experience for those who express
their ideas on the user groups and on their websites. It seems that
there are people who think that scientific texts, posted on a website
(user group), are not relevant scientific texts. I mean on a text
which is obviously the original scientific text.

Vladimir Odrljin
=====================
Regarding the rejection of my paper D. Mladenic sent me the following:

“Reviewer nr.1 comment:
Major remarks:
In general, the idea of the research is not clearly represented and
the paper is not well-structured.
Introduction section of the paper should contain more concrete
description of the research problem (significance, motivation and
possibly the list of contributions).
It would be necessary to add a Conclusion section which would
summarize the main achievements and key results of the research.
In addition, it would be useful to include in the paper a Related work
section with an overview of existing methodologies and various
approaches applicable for a given research topic. Besides it, the
comparison with other relevant methodologies could be made and the
list of references (literature cited) could be augmented. It would
help to explicitly state the originality of the performed research.

Minor remarks:
Clarity of the article should be improved. All examples, tables and
formulas should be enumerated and the text of the article itself
should be formatted in a more suitable way for reading.
As well, it would be helpful to give examples along with definitions.
At the same time, instead of using practically the same example more
than once (see subsections 3.7 and 3.8), the references on the used
example should be made.
Furthermore, several references to cited literature are missing (see
subsection 4.2.1).
In addition, references to new concepts, new terms and formulas
introduced in the paper should be done in a coherent way. In
particular, for the reader who is
reading the subsection 3.3 it might be inconvenient to refer to the
definitions in the subsections 4.2.1 and 4.2.2.

Finally, several English phrases should be reformulated and spelling
mistakes should be corrected:
- "According to G. Frege, two concepts are coextensive if every thing
that satisfies either satisfies the other" (see subsection 4.2.1);
- "We assume that the m-entity matches an entity if all it's the m-
attributes match the corresponding entity's attributes carried by
information" (see subsection 4.2.2);
- "5 Determining Plurality - Identifying And Istinguishing
Entities" (see section 5). “
=====================

On Jan 11, 12:53*am, vldm10 <vld... (AT) yahoo (DOT) com> wrote:
In my message 25, from Jan 9 2011, I wrote that in the first version
of the paper "Anchor Modeling" which was written in 2009, I could not
find reference [19] on the given web address. I have now found it, but
it seems the reference was moved to the new version of Anchor Modeling
from 2010 and new web address. The corresponding reference is [25].
In [25] the authors write that they use the surrogate key. See page
2 : “Hatt(C,D,T) contains, as indicated above an anchor surrogate
key”.

(i) “Anchor Modeling” is based on the 6NF, which is evident from the
title: “Anchor Modeling an agile modeling technique using sixth normal
form for structurally and temporally evolving data”.
In this thread in my message from Oct 5, 2010, I presented the case of
a relation that has mutually independent attributes. In this example
the whole relation is in 6NF. So here “Anchor Modeling” would not
work. This means that Anchor Modelling is not based on 6NF and that,
in fact, its basis is unknown.

"Anchor Modeling" starts at the conceptual level with structures.
However, the authors have not proven that we can get (for example) the
concept of the corresponding entity from these structures. So we can
pose the question, why should anyone believe “Anchor Modeling”?

In “Anchor Modeling” the authors extensively use the transition from
one data model to another data model. But they neither explain nor
define this transition.
In my message in the thread from Oct 5, 2010 I wrote that this problem
was solved in my paper from 2008. I used binary structures and the
following two mappings: the first mapping is a schema mapping, and
the second mapping is between instances of the data models.
In this situation both models have the same semantics. I believe that
this is an important result. (see also my message 16, from August 6,
2010)

(ii) Let E1 be the entity in the "Anchor Model" whose anchor key = 234
and which has three attributes that in time t1 have the values v1, v2,
v3 respectively. One can insert another entity whose anchor key = 567
and whose three attributes at the same time t1 have again the values
v1, v2, v3 respectively.
So we get two entities which have the same attribute values in the
database. This implies that we have two entities in the real world,
which have the same attributes in the time t1. These two entities have
different surrogate keys. We know that this is nonsense in the ER
model and Relational model. But we also see that "Anchor Model"
supports this nonsense. So anybody can enter the same entities with
different suroggates.
In this example, a variety of combinations and variations can occur,
especially since the authors of Anchor Modeling allow the deletion of
erroneous data.

(iii) Today the vast majority of keys use the industry standard,
probably more than 90% of databases use this type of keys. For
example, VIN, Bank account, SSN, etc. In this case too "Anchor
Modeling" does not make sense.

(iv) The authors of "Anchor Model" did not show "meta data" in their
solutions. In fact "Anchor Model" cannot solve structures with "meta
data".

Vladimir Odrljin

On Mar 11, 4:28*am, vldm10 <vld... (AT) yahoo (DOT) com> wrote:

1.
Sometimes we need additional techniques in order for a database
solution to work. We need additional techniques because the solution
does not work on its own. In this case “Anchor Modeling” needs some
additional technique.

2.
Here is another example:
Let E1 be an entity from the real world with three attributes that
have values v1,v2, v3 respectively at time t1.
In “Anchor Modeling” the following situation is possible: one who
wants to contest the “Anchor Modeling”, can enter the following:
First step: (12, v1, t1), (12, v2, t1), third attribute is null.
12 is the surrogate key, in parenthesis are the corresponding
“historized attributes”, all of which belong to the entity E1.
Note that a person can enter any number of instances of the entity E1
when one or more attributes have null value.

Second step: Later, the data entry person can enter (for example) the
following: (12,v4,t1) - which is intentionally a wrong value (v4) for
the third attribute of entity E1. The company sues client E1.

Third step: Then, the data entry person deletes (12,v4,t1) as wrong
data - since the authors of “Anchor Modeling” allow the deletion of
erroneous data - and enters (12,v3,t1), which is correct.
The company loses the case because it no longer possesses evidence.

In this example, a variety of combinations and variations can occur,
especially since the authors of “Anchor Modeling” allow the deletion
of erroneous data and that one or more attributes can have null
values.





3.
A surrogate key cannot solve fundamental problems in database design
theory.
To clearly portray this statement, I will use the following example:
A Honda dealer receives 200 Honda Civics to sell. All these Hondas
have the same attributes.
If we were to use a surrogate key here, we would get 200 Hondas with
the same attributes but different surrogate keys. Of course, this is
nonsense. The VIN (vehicle identification number) , which is not a
surrogate key, was introduced.

From this example, we can clearly see the following:
- “Anchor Modeling” (Surrogate Key) cannot solve a large number of
problems of this type
- I am not sure that the authors of “Anchor Modeling” understand
important theoretical issues related to this example.
- In my paper, this topic has been theoretically explained and
resolved. In my paper at http://www.dbdesign10.com (from December
2007) I introduced “distinguishing” which can be applied for the
identification of entities. We can note that “distinguishing” implies
that in this case Leibniz's law doesn’t hold true. (see also my paper
at http://www.dbdesign11.com from 2008, section 5)


4.
Here are a few well-known weaknesses of the surrogate keys:
(i) ) It is impossible to externally verify a surrogate key, while
industry-standard keys are externally verifiable. For example a bar
code or passport id are externally verifiable.
(ii)
Different companies can assign different surrogate keys, defined on
distinct domains that denote the same entities.

On this user group, there were detailed discussions about the
surrogate key related to my paper from 2005. Here is the link to my
thread from September 23, 2005 on this user group:
Database design, Keys and some other things
Here you can see some interesting posts, for example, posts 27, 25 and
62 from Anith Sen, Joe Celko and James Goulding.

5.
I introduced the idea of an identifier of an entity and of an
identifier of a relationship in my paper from 2005 at http://www.dbdesign10..com
.. In Section 1.1 of this paper, I wrote “…every entity has an
attribute which is the Identifier of the entity or can provide
identification of the entity. This Identifier has one value for all
the states of one entity or relationship.
”
Note that in this definition I wrote “… or can provide identification
of the entity”.
This refers to anything that can provide identification of an entity
(including a surrogate key if it can provide identification of the
entity). The surrogate key is a special sub case of the mentioned
definition. The surrogate key is a very limited solution. My papers
are more general, they are about identifications rather then about
keys.

Without my procedure (a) surrogate keys are worthless (I described
procedure (a) in this thread in my post from 26 May) . Procedure (a)
is important for databases, but by itself, it cannot be a solution for
databases. There are others things which must be implemented.

Procedure (a) is also important for semantics and for identification,
see for example Ship of Theseus. It the first time solves these
problems.

Vladimir Odrljin

In this thread I showed that:
1.
"Anchor Modeling" cannot solve some major areas related to "history"
of databases.

2.
A surrogate key is only a special sub case of my solution (see my
messages 12 and 34 from this thread). See also at http://www.dbdesign10.com
Section 6.3 .
As I mentioned in the above point 1, the surrogate key is a very
limited solution.

3.
Some important theoretical solutions are incorrect.

The authors of ''Anchor Modeling'' wrote corrections and published a
new version of ''Anchor Modeling'' in December 2010. In the new
version of ''Anchor Modeling'' these authors introduced new and very
important ideas: states, extensions, binary structures, mappings
between data models and identifiers of relationships.
I introduced states and identifiers of relationships in my papers from
2005. I introduced decomposition into the binary structures in 2005
and 2006, and extensions and mappings between data models from 2008.

In this post I will concentrate on the following two:

(a) A New Definition of ''historized attribute'':
Definition 7 (Historized Attribute). A historized attribute BH is a
string. A historized attribute BH has an anchor A for domain, a data
type D for range, and a time type T as time range. An extension of a
historized attribute BH is a relation over I x D x T.

This definition degrades the ER and Semantic model. The relation I x D
x T is what E.Code unsuccessfully attempted to have in his paper RM/T.
He wrote ''In any RM/T databases there is a unary relation (called an
E-relation) for each entity type.'' Note that the ''Anchor'' in fact
is the ''E-relation''.

Note that the extension from Definition7 enables the following:
- the decomposition of data structures into binary structures
- spanning a data model over two data models (Conceptual Model and
Relational
Model). It also enables a transition (mapping) from the Conceptual
Model to the Relational Model.

Note that the authors of ''Anchor Modeling'' try to solve the
mentioned fundamental semantic and structural problems, only by
definition7.

In ''Anchor Modeling'' there is no guarantee that (binary structures)
”historized attributes” form an entity or a whole at a given point in
time. To be more precise, what is the theoretical basis for creating
these binary structures? In RM there are no entities.
On May 15, 2006, I presented a solution which explains how to
decompose a relation into binary relations. (see Section 4 at
http://www.dbdesign10.com ) .

In my paper from 2008 at http://www.dbdesign11.com I presented how to
decompose a concept of an entity, a concept of relationship and a
concept of a state of an entity or relationship into Binary Concepts.
All of this was done on the conceptual level. The binary concept is
precisely defined, as well as the conditions under which binary
concepts form an entity (see 4.2.2 and 4.2.6 in my paper). In the
paper from 2008 I defined mapping from the Conceptual Data Model to
the Relational Data Model. This data model mapping is determined by
the following two mappings: the schema mapping and data mapping.

The authors of “Anchor Modeling” give no theoretical explanation for
surrogate keys. We know that functional dependency is determined by
the real state in the Universe of Discourse. However, in this paper
there is not a single word about the surrogate keys and the real
world.
Note that every ''historized atribute'' has the attribute T. Thus, if
an entity has 10
''historized atribute'', then the entity (and the corressponding
relation) has 10 of the same attributes T. In my data model, time T is
not an attribute.

(b) The Identifiers of Relationships
In this new version from December 2010, the authors of the ''Anchor
Modeling'' introduce the identifier of a relationship (see Definition
16).

This definition is a sub case of the identifier of the state of a
relationship from my data model (see 4.2.4.1, 4.2.4.2, 4.2.5, 4.2.6,
4.2.7, 4.2.8 and 4.2.9 in my paper from 2008). Note that I presented
the main ideas about the identifier of a state of an entity or
relationship in my paper from 2005, five years prior to 2010.

Identifiers of states are very important and fundamental.

(i) In my papers I defined a state of an entity or relationship as the
total knowledge about the entity or relationship
(ii) In my paper from 2008 under 3.9 I defined knowledge about an
entity or relationship
(iii) I defined a state as a concept
(iv) The concept of a state of an entity or relationship is a definite
departure from the idea that a concept is determined only by
conjunction of properties. This is the first time that one precisely
shows the construction of this kind of concepts.
(v) In my papers, states are at the subject level, not at the object
level.
(vi) I distinguish between three realms: the real world i.e. the realm
of reference; the realm of mental; and the realm of semantics. For
instance, everyone can grasp a state of an entity in the same way,
which means that semantics (meaning and grasping of the mental) is
real and objective.
(vii) In my papers knowledge is based on facts. I determined two
important properties of facts: the facts are recorded i.e. they are
permanent and the corresponding subjects are aware of the facts. (see
3.4)
(viii) The concepts in my paper work with abstract objects (not with
physical object). In my data model the abstract objects are recorded
(written) in the memory, which is the reason why I put the prefix m in
front of their names. The abstract objects that satisfy the concept of
the states are complex because they are constructed from the other
abstract objects. This means that depending on their structure, there
are two kinds of abstract objects.
(ix) Concerning entity (relationship) changes, the following from my
paper is
significant: there are only two kinds of events related to changes. An
event which causes new information and an event which causes existing
information to be invalid after this event (this event closes existing
information). A very important consequence of my event approach is
that any change of a state corresponds to one of these two events in
the real world. This approach implies a new definition of and a new
approach to time.
(xi) I introduced the identification of a state. Every state has an
identifier. My paper is the first instance in which the identifiers of
a state of an entity or relationship were introduced. Note that the
states are abstract objects.
(xii) The identifier of a state is determined by the corresponding
concept.
(xiii) The entities involved in relationships must be in the
corresponding states.
(xiv) I introduced a procedure (a), which together with other
constructs resolves
the problem of "history", the semantics of states and changes, and
other problems. I described my procedure (a) on this thread in a post
from May 26.
(xv) My definition of the concept of a relationship determines the
keys of the relationship.
(xvi) My paper, for the first time, shows how to solve the "history"
of states of an entity or relationship.
(xvii) My paper gives for the first time an effective solution, which
decomposes any data structure of the state into appropriate binary
structure. This has been shown for the Conceptual Data Model,
Relational Model and File Model.
(xviii) My solution is of a general character; it is at the level of
databases design and concepts. Note that surrogate keys and object
identities from OOP have some elements that are on a technical level.

The main ideas for these solutions were presented in 2005 in my
papers.

None of the above listed eighteen points is included in the first
version of "Anchor Modeling".

In this thread, on 12 June 2010, I criticized the definition of a
relationship from the first version of ''anchor modeling" I wrote:
”But in section 2 there is Def2 which says: “Def2. An anchor A(C) is
table with one column”. Now it turns out that the relationships
between tables with one column
are captured through ties? Of course this is nonsense.”
I believe that the paper, which intends to resolve such fundamental
issues in database theory, cannot define them this way.
In definition13 (relationship) in the new version of ’’Anchor
Modeling”, the authors introduce “roles”. Note that Peter Chen defined
roles, a long time ago. Note that my definition of a relationship from
2008 also uses also the keys of the relationship (the keys caver
roles, see also (xv) in this post).

In this new version from December 2010, the authors of ‘‘Anchor
Modeling'' introduce an identifier of a relationship (only by
Definition 16).

Note that the identifier of state is a vital part of the following:
1. the solution for ”history”
2. the decomposition the data structures into binary structures
3. It completely defines the mapping between data models
4. It identifies the states
5. It identifies abstract complex objects,
and much more.

Vladimir Odrljin

On 6 srp, 22:58, vldm10 <vld... (AT) yahoo (DOT) com> wrote:

It seems to me that the authors of "Anchor Modeling" in this
definition do not understand some of the corresponding theoretical
requirements.

Vladimir Odrljin

On 6 srp, 22:58, vldm10 <vld... (AT) yahoo (DOT) com> wrote:



It seems that the authors of "Anchor Modeling" tried to introduce the
states of relationships with this identifier.
The states of the relationships are defined in my paper 5 years ago.
Note that the identifiers of the states of relationships enable work
with the relationship between two relationships and with the
corresponding history of this relationship.
Note that the "Anchor Modeling" is only defines relationship between
the entities.

Vladimir Odrljin

On 3 ruj, 16:50, vldm10 <vld... (AT) yahoo (DOT) com> wrote:
Given the significance of the results of my paper, published
four(five) years before "Anchor Modeling" on this user group, I have
decided to submit complaints to Springer and Data & Knowledge
Engineering publishers - the publishers of the first and second
versions of "Anchor Modeling". When I find out the results of these
complaints I will post them on this user group.

Vladimir Odrljin