The ORM Foundation

I would agree with Ken. And with John Zachman, who, I believe, would say that the original conceptual model is simply not complete. Zachman classifies by the target audence, not by the amount of content, and this makes much more sense to me.

Ken Evans:

Although Terry talks about a "syntactic data type", I feel that the concept "semantic data type" is what we are really discussing.

 

Sorry, but I disagree. An entity type has instances that are not identified by a lexical form, whereas a value type is. Both types have a semantic value, but the latter is what I believe is being referred to as a syntactic data type; that is, a data type which has a syntactic (or lexical) representation

In the Constellation Query Language, a value type (lexical type) can only be defined by the use of the phrase is written as, a decision I made in order to underline the lexical aspect.

In ORM2, a value type may be further constrained (from the possible values of the base type) by a value type restriction (a list of values or value ranges, possibly open-ended). A role played by a value type may be further constrained by a role value restriction (of the same form).

Sorry Clifford, I don't understand what you mean by

Clifford Heath:

An entity type has instances that are not identified by a lexical form

 

Here is my take on the situation:

1: The fundamental element of an object- role model is the elementary fact.
An elementary fact is made up of a statement such as "student writes dissertation"  PLUS the constraints.
In other words whilst you can write the statement independently of the constraints, it does not become an elementary fact until you add the constraints.  
 
2: The "object" in an elementary fact is a placeholder for a set. (aka "domain")
Thus, the elementary fact is not complete until you have specified the extent of the set(s).

That's why I see the data type as an essential component of an elementary fact in a conceptual model.

Ken

Ken Evans:

I see the data type as an essential component of an elementary fact in a conceptual model.

 

It is, of course, and I agree with everything else you wrote. But in ORM, the distinction between a ValueType and an EntityType is that a ValueType has an accepted lexical representation. I can write a Name, but I can't write a Student. Note that a lexical representation can be any form of symbols, as for example twos-complement binary notion is lexical. Some lexical representations have complex structure, so that the object type could be modelled at finer granularity, such as a Date, or a String containing escape sequences, but the important thing is that at least one lexical form is accepted for that type. I'm not aware of any lexical representation of a Student, a Company, or any of the other EntityTypes in my models.

This was in the context of your response to Andy Carver's

Andy Carver:

how does that imply we need syntactic data types in our conceptual modeling

when you replied

 

Ken Evans:

Although Terry talks about a "syntactic data type", I feel that the concept "semantic data type" is what we are really discussing

Andy's point is that all our object types are semantic, and we can do semantic modeling without discussing any lexical aspects. When we move to implementation, we need to agree on the lexical representations we will use in different contexts. Each value type will typically have at least two different lexical representations - one for the machine and one for the human.

Clifford Heath:

a ValueType has an accepted lexical representation.

Hmm, that's curious, I can't find anything in the Big Brown Book about "an accepted lexical representation"
From Terry's description (page 10) of the difference between an entity type and a value type I infer that the only difference is that an entity type has a reference scheme but a value type does not.

And regarding "lexical notions" my take is that the names of ORM object types (both entity types and value types) are arbitrary sets of symbols.
In other words, the names do not have any meaning.

Clifford Heath:

I can write a Name, but I can't write a Student

Interesting point (the significance of which I have not yet grasped).

However, it seems to me that:

1: A "name" is an arbitary set of symbols that is used as a label for something else.
2: The arbitary set of symbols "Student" is often used in natural language as a label for a person who is undertaking a course of study.
But the link between the name "Student" and a real student is itself arbitary. (The map is not the territory).

 

Clifford Heath:

Some lexical representations have complex structure

I interpret your use of the term "complex structure" to be a reference to things like "date codes" such as the code for today's date: 090927.
As I see it, a date code is the same kind of things as a manufacturing part number code (See example of Honda Motorcycle parts at: http://www.kaila.net/tl125/tl125partcode.html)

Furthermore, my interpretation of ORM is that the fact that you can extract the month 09 from 090927 is not relevant in an object-role model.
090927 is just a unique number that refers to a specific day in the Julian calendar. (bound of course by the Y2K type constraints etc.)

 

Clifford Heath:

Andy's point is that all our object types are semantic, and we can do semantic modeling without discussing any lexical aspects.

And I fully agree with Andy. As I see  it, this conforms to the view that a mathematical structure such as A = B*C is "meaningless" until  you say things like "Let A stand for..."  

 

Clifford Heath:

Each value type will typically have at least two different lexical representations - one for the machine and one for the human.

Sorry Clifford. You have really got me here. I don't understand what you are trying to say.
Surely the "machine representation" is just something like : 10101111001110101010 and I can't see what is "lexical" about that.

In fact this whole "lexical" thing seems to be a source of confusion.
Lexicographers are the folks who write dictionaries.
To the best of my knowledge, a lexicographer searches through lots of text and makes a record of how a set of symbols e.g. "right" has been used in various contexts. As such, lexicographers are best seen as symbol archaeologists rather than "law givers on the meanings of words"
In other words, there is no "right" meaning of a word.

Dictionaries just give a list of contexts in which the word has been used. This is not much different that providing a list of the places you visited when you were wearing your favourite sweater. The fact that you have worn that sweater in 100 places in the past, does not mean that tomorrow you won't wear the sweater in a new place (the 101st).
So it is with words. Just ask a poet or one of the creative folks in an advertising department.

Anyway, I suspect that you have a perspective that I have not yet understood...

 

Ken Evans:

I can't find anything in the Big Brown Book about "an accepted lexical representation"

Page 65, last paragraph. I use a slightly different description, but my meaning is the same:

Terry Halpin:

A value is a constant that is self-identifying in the sense that when you see the constant written down in some context you always know what is being referred to.

In other words, both you and I, without being told, know what the written representation means - we both accept the representation as meaning the same thing.

Ken Evans:

regarding "lexical notions" my take is that the names of ORM object types...

I don't believe I made any reference to the names of object types, so this (and most of the rest of your posting) has no further relevance. You have started talking about the map, when it seemed clear that I (and Andy) were talking about the terrain.

Ken Evans:

Surely the "machine representation" is just something like : 10101111001110101010 and I can't see what is "lexical" about that.

The language of "32-bit big-endian two's complement binary numbers", the alphabet consists of the two binary digits, and a valid sentence is composed of 32 of them. In the context of that language, if I speak 32 such digits, you know what integer is signified. In another language, say, little-endian, or 8-bit, or one's complement, a different integer or integers is signified. This is almost as basic as language can get (ref C. Shannon!). Almost as basic, because it's still structured; one bit in two's complement is always the sign bit.

Now, to refer to the original issue I addressed. Andy Carver claimed that your argument had failed to establish that syntactic types are needed in modeling the UoD. You had made a valid argument about choice of words to be used in representing the model, and the need to clearly identify the sets of instances to be represented by values, and then seemed to extrapolate it to the need to assign syntactic data types to the value types contained in that model:

Ken Evans:

So, when you define an elementary fact, you need to be specific about the set of things to which each object refers.

This is quite true. Then you extrapolate:

Ken Evans:

This is why I see the data type as being an important part of the semantics of a conceptual object-role model.

I think the issue is that you are using the term "data type" in a non-standard way.

The data type implied by the term syntactic type merely refers to a choice of lexical representation of the values of a value type, such as whether to represent a number as a string of decimal, octal, hexadecimal, or binary digits. The choice of representation is not a part of the semantics of the value type, so Andy called your argument into question.

Terry's use of the term "syntactic data type" on page 219 has no relevance (that I can see) to the choice of names used to express a model, nor to the choice of symbols used to represent values in the model (such as in value restrictions); only to the choice of representations used for instances of the value types included in the model.

Faced with Andy's challenge, you promptly tried to redefine the argument as being about semantic types. To most of us, it's obvious that both value types and entity types are semantic. They are not both syntactic however; only value types are, as only value types have the characteristic that they can be "written down" in an accepted representation, hence only value types need data types; and even then the data type is not semantic, but purely lexical.

Clifford Heath:

I use a slightly different description, but my meaning is the same

If your meaning is "the same" why use a different description?

Clifford Heath:

The language of "32-bit big-endian two's complement binary numbers",

Interesting, I'm wondering if this is a mix up between natural language and formal language. They are not at all the same thing.
As I see it, lexicography applies to natural language but not to formal languages.

From dictionary definitions, the term "Lexicography" and all related terms relates to the study of natural language. The lexicographers (the folks that make dictionaries) are like archaeologists in that they record the uses of that people have made of words in various contexts.

Formal languages, such as binary dialects (8 bit, 16 bit, 32 bit and so on) have prescribed meanings and permitted operations and thus form a complete and closed universe of discourse on their own. FORML has the same properties.

Clifford Heath:

I think the issue is that you are using the term "data type" in a non-standard way.

In Hayakawa's excellent book "Language Thought and Action" he makes the point that each use of a word is unique because each context is unique. (You can never step into the same river twice).
So whilst it may be true that I am using the term "data type" in what you call a "non-standard way", as I see it, I am just making use of that wonderful property of the natural language called English, to borrow a concept from one context and apply it in another.   

So from my perspective I was not "trying to redefine the argument" . What I was (and still am) trying to do is to say that there is a place for the data type concept in a conceptual model which is not at all "syntactic" since it serves to explain the conceptual meaning by acting to limit the scope of the sets that are referred to in the elementary fact.

The fact that data types are used in computer programming languages is just a convenience in that it makes it easy to transform an object-role model into a logical model. 

On page 219 of the Big Brown Book, Terry mentions the idea of a "syntactic data type" as a "weak form of value type". And this relates to what I'm trying to get across in that (as I see it) a data type is nothing more or less than a constraint on permitted values and permitted operations.

From a FORML perspective, the name of an object type is just an arbitary (but unique) set of symbols.
The fact that we choose to use object-type names that are also meaningful in natural language is a very useful convenience in that the names act as a bridge between formal language and natural language.

But I suggest that any "lexical" properties of object type names are an illusion because the concept "lexical" relates to the domain of natural language and not to that of formal language.

At least that's the way I see it...

Ken