The ORM Foundation

Terry Halpin:

I allowed value types to have implicit supertypes, which I now regard to be  based on the datatypes from which they draw their values

Very interesting - this goes to the very heart of the data type debate. I implement data type in CQL/ActiveFacts by requiring every value type to have a supertype, and assuming that any such supertype which is not known to be another value type is treated as if it were a datatype (it's implicitly called into existence, even though it may not be recognised by the mapping layer). In my implementation, there's thus no distinction between a supertype which is a data type and an explicit supertype which is another value type. Perhaps there should be, but I've not come across the need for it yet. Matt keeps telling me that they are very different things, and I'm sure that in some contexts that's true - just not contexts in which I've yet had to be concerned. In only one respect the basic data types are special in CQL; they match up with data types known to the languages CQL maps to (Ruby, SQL, etc), and the mapping layer knows about that. The "special-ness" comes from the mapping, which forms the context in which the model is interpreted.

I recall finding an unexpected side effect of this however, though I forget the example case (it was in a version of Matt's proposed FBM metamodel). While processing a join constraint from NORMA, I ignore any join path and recompute the default join path which NORMA would. Treating the data type as a supertype can create an additional possibility for the join path. In some cases, there are two possible implicit join paths (where there's an objectification join), and I was choosing the path via the data type, where NORMA chose the path via the objectification join. I had to introduce special handling to disallow implicit subtyping joins when there's an objectification join available. As a result, there may be cases that NORMA allows which ActiveFacts disallows, but it would have to be pretty arcane. If I was worried, I'd read NORMA's generated join path and just use that.

Regarding Temperature and Height, I was meaning the associated values, as you pointed out. Sorry for the oversight. As you will understand from the above, I also have no problem with them being compared, but that comparison is strictly outside the domain model; it arises from the data type metamodel.

Hi All,

I am new to ORM and to this forum. However, I am coming from the closely related field of formal ontology development within the biomedical domain and, as I was reading this thread, I had few thoughts that you might find useful, or at least interesting. I'll comment on individual posts in this thread instead of trying to making one lengthy post.

A little background abut myself. I am involved in developing biomedical ontologies and over the past few years there has been a push for adopting few principles for analyzing and understanding our world in order to develop better formal representations. This is not the place to describe the principles in detail but my comments will be based on these principles and other philosophical approaches to some of the issues discussed in this thread. Briefly, there is a "realist" view of the biomedical domain that is formalized in the "Basic Formal Ontology (BFO)" upper ontology [1,2]. Domain experts then use the "realist" view (or philosophy), and its representation in the BFO, to represent their domains as extensions of the BFO. At this time this is mostly done by using description logics but there is also a push for adopting Common Logic as the preferred representation.

My main interest in ORM is its first order logic foundation and its ability to clarify the process of developing a flexible domain information model. I am trying to merge the logical "definitions" of entities (types, classes, universals, etc) that are being created in the form of biomedical ontologies with the ORM approach that allows a more flexible way (compared to RDF or the record-based approach of ER and OO modeling) for modeling "domain information" that is related to instances of the entities defined in the ontologies.

[1]  http://www.ifomis.org/bfo

[2]  http://www.ifomis.org/bfo/documents/manual.pdf

Cheers,

Shahim

mnnoon:

What is the difference between a value type and an entity? 

One way that helps me keep the distinction clear is the following. Values (numbers, strings, social security numbers/strings, ids, etc) are predefined members of a set that is defined by rules or axioms in order to create the members. For example, the natural numbers are predetermined instances that belong to the set of natural numbers because the definition, axioms, and operations (the algebra) of this set sort-of creates the instances and nothing else is needed to create them.  In other words, there are no natural numbers without the axioms that define them and they are sort of primitive things where nothing else can be said about them other than the fact that they satisfy the axioms. These systems are usually represented as Datatypes in computer systems. I do not agree that names are values just because we use string values to represent them. I'll comment on names in another post.

Entities (as types or sets) on the other hand are sets of things that would still exist if we didn't formally define a set for them. Also, the individuals in the entity types are not all predefined the same way numbers and strings (in a formal language or a coding system) are predefined. It is also difficult to create a simple algebra for them the same way we have created algebras for numbers and strings. The entity type Person (as a physical human body) is a set that keeps getting larger as new humans are created, there is no predetermined instances of the set Person. Also, there are a lot of interesting facts that can be said about an instance of Person regardless of the sets that an instance of Person belongs to.  Another difference is that the entity/type Person is dependent on, or becomes evident ofter, its instances are observed and characterized while the entity type Number is axiomatized in order to create its instances.

Cheers,

Shahim

John Saunders:

While I agree that Height is not a simple value type (it is not self-identifying), I'm afraid I don't see that it is actually an entity type:

1. You can't point to a Height and say, "look, there's Height 60 inches" in the same way you could point to "Person named John Saunders"
2. What happens when the Height changes? My brother is an inch taller than I am. If he loses an inch with age, do we suddently both share the same Height instance? What happens to the original instance? Is it now orphaned?

For 1 you can actually point and say that there is an instance of Height and for 2 it is not the height that changes, it is the height measurement that changes.

According to the philosophy adopted by the BFO ontology (described in earlier post) [1] there is one upper level category named "Quality" that represents the things that we commonly refer to as "properties". The "BFO:Quality" is a subcategory of higher level categories named "SpecificallyDependentContinuant" and "DependentContinuant", which represent the categories of things that depend in their existence on what is called "IndependentContinuant".

The BFO framework says that each one of us has a specific instance of the Height entity (that could be assigned some unique identifier if needed) that never changes. I have one instance of Height when I started to exist and the existence of my Height instance depends on my body's existence. My body is an instance of an IndependentContinuant that "bears" and instance of Height.

My instance of the Height entity is not the same as the various instances of the HeightMeasurement entity that are obtained/created about my Height instance at various times. There is a common confusion in the medical field about entities that are not about something else and entities that are always about (not property or quality of) something else. My single instance of Height is not about anything, it just exist , regardless of whether there are any instances of HeightMeasurement about my height.The same thing applies to blood pressure vs. its measurement, pain vs. the subjective assessment of it, etc.

This approach is being formalized as an extension of the BFO in the form of the "Information Artifact Ontology (IAO)" [2] to develop a general formal representation of "informational entities" that are always about some other entity. It is within the IAO that values (labels of values to be more correct) become useful.

Taking Height as a simple example. Height is a one dimensional quality (a Length with a topological orientation) that could be assessed or measured by marking a point on some other one dimensional entity. We do this when we ask our kids to stand against the wall and mark a point on the wall to watch them grow. To make this idea of assessing a Height instance more formal, we would use the straight line axioms from geometry and try to mark points on a line to "measure" a Height. However, we still need a way to describe where this point is on a line and this is where it becomes useful to divide the line into standard discrete parts (the various length units) and then use the system of numbers to identify how many parts are being used as a measurement for an instance of Height. We could also decide to only measure in discrete units and then predefine a standard set of named points on a line and give them randomly created strings as labels. However, by using integers, and the properties of their axioms, we would greatly simplify measuring length and enable us to add and subtract measurements in very useful ways. This same idea applies to Temperature vs. TemperatureMeasurement and most of the other entities that need numeric or string "values" to make an assessment of, or a reference to, some other entity.

I went into too much detail about measuring a height as an example for how to be formal in measuring qualities and to show how value systems (or value sets) and their axioms become useful when we create informational entities about other entities. The height measurement case is very straightforward but many qualities and qualitative assessments in the biomedical field are very difficult to analyze and represent in a formal way. I am still learning about this issue but [3] would be an interesting reading and a good start for anyone trying to develop a clear formal approach to this problem.

[1] http://www.ifomis.org/bfo and http://www.ifomis.org/bfo/documents/manual.pdf

[2] http://code.google.com/p/information-artifact-ontology/

[3] http://comp.uark.edu/~efunkho/determinable.pdf

 Cheers,

 Shahim