The ORM Foundation

Is there an official (!) exchange language for ORM2 or are there plans to create and support (!) such a language? I know the paper "A markup language for ORM business rules" by Demey, Jarrar, and Meersman and surely each tool (NORMA, ORM Lite/GanttPV, DogmaModeler etc.) has it own file formats but without standardized exchange language to import and export model between different tools, you are stuck to one tool - and you end up in modeling in a proprietary tool language instead of ORM. Which ORM exchange language standard should I build on to create my own ORM-based tools? Is there any interest of exchange at all in the ORM community or do you prefer everyone having "his own" dialect of ORM ;-) ?

Hi Jakob,

That is a very interesting question.
But I would like to explore what you mean by "an exchange language"

As I see it, in an ORM project, the following "languages" are in play.

The DOMAIN LEVEL
This is the set of symbols in the domain (e.g. Pilot's English, Navigator's Engilsh, Oil Rig English, Chromsome engineer's  English and so on.)

THE ORM LEVEL: ORM (1 or 2)
At this level we have the answers to questions such as "What is an object?", "What is a Role?" and "What is an elementary Fact?"
The ORM1 symbols are defined in Terry's 2001 book and the ORM2 symbols are defined in his 2008 book.

THE FILE LEVEL
As I understand it, ORM1 files can be converted to XML and ORM2 (NORMA) files are already in XML format.

 

So at which of these three levels do you see a need for "an exchange language" and between what things would the language be used to "exchange"

Or have I misunderstood something in your question?

Ken

 

 

  

I mean a formal expression of the ORM level for exchanging ORM models in files.

The graphical representation of ORM2 is defined in Terry's 2008 book, especially the "ORM Glossary" gives a good summary on 6 pages. The "ORM2 Graphical notation" from 2005 (Technical Report ORM2-01) is less expressive and the "textual notations" mentioned in it are missing in the ORM2 glossary, so there could be some small irritations what is definitely part of ORM2 and what is not (is ORM2 still evolving or is it fixed?) - but in general semantics and visual grammar of ORM2 is more or less well defined.

In addition to the graphical representation there is a translation to pseudo natural language statements. I am not sure whether it covers all of ORM2 and whether you can write a parser that converts this natural language statements back into a ORM2 model.

But to exchange ORM2 models we need a well-defined formal representation of ORM2 in a file format that  can be mapped to the graphical representation and vice versa. So in fact I mean the file level. NORMA files are XML, but first I found no specification of NORMA file format and second NORMA is not ORM2 - it's a tool to work with ORM2 models. Jarra's ORM-ML is another approach, that may suit as an exchange format for ORM2 models, but it looks like it is not officially supported and pushed forward by the ORM foundation. At the moment it looks like I have to define my own format to define ORM2 models in a non graphical way.

Maybe this comparision helps: There is the RDF model as defined in http://www.w3.org/TR/rdf-concepts/ and there is RDF/XML to formulate RDF statements in XML. But you could also use Notation 3 to write down RDF. What I am looking for is a specification how to write down ORM2 models. The specification should be propagated by ORM Foundation so different tools can support import and export methods to exchange ORM2 models.

With an exchange language you could for instance create a model with NORMA, export it and analyze the model with another tool. Or you could create a model with one tool and use NORMA to create the graphical representation.

Thanks and Greetings
Jakob 

jakob.voss:

I mean a formal expression of the ORM level for exchanging ORM models in files.

OK - For clarification, please confirm that your phrase "exchange models in files" means the same as "exchange files (of ORM models)  between two different ORM tools"?. If so then won't it be necessary to specify which tools you mean?

jakob.voss:

The graphical representation of ORM2 is defined in Terry's 2008 book, especially the "ORM Glossary" gives a good summary on 6 pages

  I'm assuming that you mean pages 896 to 902 ? (My copy of Terry's book spreads this across 7 pages)

jakob.voss:

In addition to the graphical representation there is a translation to pseudo natural language statements.

Yes, I use the NORMA verbalizer to do this. In the past I have used the verbalizers in InfoModeler, VisioModeler and VEA. However, I find that the verbalizer in NORMA is more comprehensive and more flexible than the earlier verbalizers.  For example, because the NORMA verbalizer works "instantly" you can change your graphical model and immediately see the verbalization. Personally, I find it much easier to work from the ORM graphical model because it is precise and less verbose than any of its transforms. To demonstrate this point, I have made a simple object role model about tools and file formats. The diagram below shows the object-role model. And I have posted a file in the Library Tools>NORMA>ToolFile_ORMdiagram.doc to show the NORMA verbalization and its XML representation (as generated by NORMA).

I hope that you will agree that the ORM2 diagram is simpler than its verbalized transform and vastly simpler than its XML transform. 

jakob.voss:

is ORM2 still evolving or is it fixed?

I think that ORM2 is still, and will continue to evolve - albeit rather slowly.
However, Terry can tell us more about this.

jakob.voss:

NORMA is not ORM2 - it's a tool to work with ORM2 models.

True. But it seems to me that what you are asking for is "exchange between tools".  

jakob.voss:

I found no specification of NORMA file format

To the best of my knowledge, NORMA models are stored in a special class structure which I don't think of as a "file format".
Matt should be able to elaborate on this.

jakob.voss:

Or you could create a model with one tool and use NORMA to create the graphical representation.

NORMA has an "import" feature that can (presently) import from SQL Server and MySQL.
This import feature generates an ORM2 model. That's the best I can suggest at present.

In conclusion, I am reminded of the late Edsger Wybe Dijkstra's observation that one of the biggest challenges of computer science is to avoid generating unecessary complexity. 

"It is time to unmask the computing community as a Secret Society for the Creation and Preservation of Artificial Complexity." http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1243.html

 Why do we need so many ORM tools?

Ken

Jakob,

 As part of my Master's degree studies with Terry Halpin, I started work on a textual representation of ORM2 models. Hopefully, this notation will fill the need you have described. It is part of an larger project to define a standard ORM2 constraint language. To date, I have completed a first draft of the language and written a paper that shows how different ORM2 model fragments from the Brown Book could be represented. I have also written a parser for the language.

While the first version has many good characteristics, it still needs work. Terry has provided some valuable suggestions for improvement. My intention is to revise the language into a version two and then provide implementations for at least NORMA and ORM-LITE/GanttPV. (If anyone would be interested in funding this work, please let me know. ^_^)

My current top priority is to research some issues dealing with code generation from ORM2 models.

Regards,

Brian 

Jakob, Brian and Ken

I posted a reponse earlier to Jakob, but somehow it got lost. Work has begun as a joint effort between the NORMA team and PNA to specify a common metamodel for ORM. When completed, this draft will be made available to others in the ORM community, for modification and then submission for ratification by the ORM Foundation (hopefully later by standards bodies such as ISO). The initial work is modeling the semantics of the ORM graphical language, with a view to extending this to textual rules later. An XSD for this metamodel could be a candidate for a standard interchange format for fact-oriented modeling tools.

In addition, work is ongoing independently by a number of ORM tool vendors to specify a surface syntax, initially English-based, for a formal, textual language for ORM. Brian's work and Clifford Heath's work with ActiveFacts provide two of many examples of this. Hopefully at some future time the ORM community might agree upon a standard textual syntax which could also be used as an interchange format.

Cheers

Terry

Terry, Brian, and Ken

Thanks for your replies. Looks like at the moment there is no reliable way to exchance ORM2 Models but to use the graphical representation. Surely you can exchance between different installations of NORMA but this does not help for several reasons - for instance NORMA is based on MS Visio which is not free software, so the practical impact of ORM2 in Linux environments is still very limited.

The definition of a complete metamodel of ORM2 looks promising. If the model is detailed and clean enough you should be able to losslessly transform between different formal representations and file formats like Brians textual representation and an XSD representation. My current research includes transformation between different modeling languages (UML, EER, ORM2), methods (Concept Maps, Euler Diagrams...), and logical representations of models (especially RDF) so tools to read, transform and write ORM2 models are welcome.

Regards,
Jakob

Hi Jakob,

Many people read these posts so I feel a need to clarify your comment. 

jakob.voss:

for instance NORMA is based on MS Visio which is not free software

The facts are as follows:
Visual Studio is not the same thing as Visio.

ORM2: Is implemented in NORMA which requires Microsoft Visual Studio 2005 or Microsoft Visual Studio 2008.
ORM1: is implemented as a component of the tool "Microsoft Visio for Enterprise Architects" (VEA) This tool requires Microsoft Visual Studio 2003 or Microsoft Visual Studio 2005.

As you say, it is true that whilst NORMA is free, it does require Visual Studio - which is not free.
But in an ORM project, the cost of software is a minute fraction of the cost of the project so from a business perspective, the cost of the Visual Studio licence seems not to be of much relevance. Furthermore, many people argue that Linux is not free. For example, read Marc Wagner's article at  http://education.zdnet.com/?p=1137

Regarding your research, in the dissertation of my recent Masters degree, I compared UML, ER and ORM. My aim was to test the hypothesis that "ORM based methods require at least 25% less effort than alternative methods such as UML and ER". The evidence revealed by my research supports the fact that my hypothesis is true. 

So whilst I think it may be of "academic interest" to look for a way to make transforms between the methods you mention, the only thing that seems to matter to business oriented people is "Which approach is the most effective?"

Good luck with your research 

Ken

Dear Ken,

Sorry for having to disagree explicitely. You are right that from a total cost-based point of view for an average developement project, the price of using NORMA is no problem. I am not talking about price (free as "free beer") but about the right to use and modify the software (free as "free speech").

The idea of free software includes that if you want to use parts of it in another project, or if you have an idea to improve the software, you are allowed to do so (as long as you license your work under the same license, if it is a viral license). While NORMA is licensed under the Common Public License (CPL), Visual Studio and Visio are not. Moreover the CPL is not compatible with the most common Free Software licenses GPL and Apache License / GPL3. So if you want to do anything with ORM in a project that is based on Free Software, there is little to build on. Moreover at the moment there is not even a way to write your own tools to work with ORM models and exchange this models with NORMA because of a lacking exchange format. Terry and Brian showed that this situation will hopefully change (by the way: will you publish your parser as Free Software, Brian?).

To talk about "effort": It all depends on the context and how you measure effort. If your work is based on Open Source software, the effort to use ORM is much higher than if you are a company that uses Windows, .NET and similar enviroments anyway. I guess that is one reason why ORM is much less used than EER and UML. For on overview of data modeling practise see Graeme Simsion (2007): "Data Modeling Theory and Practise". Is there a similar study on ORM usage by the way? I'd strongly bet that most features of ORM are rarely used in real world applications at all. With an exchange format you could automatically check ORM models to find out what features are used and you may even detect common mistakes and pitfalls in ORM modeling.

Hi Jakob,

You don't need to apologise. The only kinds of discussion worth having are the "explicit" type  so thanks for the clarity 
If its OK with you - I'll skip the general debate on "free software".

The perspective I prefer to take is that of the businessman who has a "business problem" to solve and needs help in solving it.
So for me, statements such as "We can't solve your problem because we have chosen to use an open source technology platform prevents us from deploying the most appropriate tool"  are likley to get a business response of "OK - so change your platform"

jakob.voss:

I guess that is one reason why ORM is much less used than EER and UML

Wow! That's quite a leap ! You must be an expert in creative marketing spin.
It seems to me that the reason that ER and UML are used rather than ORM is down to one main thing: "marketing muscle".

   

jakob.voss:

For on overview of data modeling practise see Graeme Simsion (2007): "Data Modeling Theory and Practise". Is there a similar study on ORM usage by the way?

Thanks for the tip. You might be interested to know that used Graeme's work in my Masters dissertation and (with his agreement) defined and conducted a survey that re-used parts of his PhD thesis - very similar to his book - which I have referenced on the "Research" page of this website. You will also see that I posted an interim report of my "Design or description" survey in the Library on 24 May 2008. 

Anyway, his main focus was to discover whether data modeling is about "Describing the world" or "Designing the world". Graeme concluded that data modelers actually "invent" the data model and my survey supported his findings.

jakob.voss:

I'd strongly bet that most features of ORM are rarely used in real world applications at all.

Well - I think you would win your bet.
However, the real question is "why".
My answer is that ORM can do a lot more than UML and ER and "business people" have not yet woken up to the need for the features of ORM.

jakob.voss:

With an exchange format you could automatically check ORM models to find out what features are used and you may even detect common mistakes and pitfalls in ORM modeling

Now I must confess some confusion in what you are trying to say here.

It seems that you are asserting that
1: There is a need to check ORM models to find out what ORM features are used"
It is my understanding that "the ORM features that are used an a model" are those features that are needed to adequately define the elementary facts in the universe of discourse".  I'm curious to know what other purpose there might be in finding and answer to this question.

2: ORM models contain "common mistakes and pitfalls" that could be detected by some external algorithm.
I don't doubt the facts that "some ORM models contain mistakes" and that "there are pitfalls in using ORM".
However, I'm curious to know how the "external algorithm" could uncover the "mistakes" and "pitfalls" without knowing about them in the first place.
And if you know about the "common mistakes" and "pitfalls" surely the best use for such knowledge is to use it to avoid making the common mistakes and to avoid the pitfalls in the first place.

Or have I misunderstood something here?

 Ken

 

 

   

Dear Ken,

Allright, lets finish the discussion on formats and Free Software and skip to the how and why of ORM :-) Thanks for pointing me to your interesting research - I am looking forward to the final dissertation. Is there a summarizing paper yet? 

Ken Evans:

It seems to me that the reason that ER and UML are used rather than ORM is down to one main thing: "marketing muscle"

Surely there are multiple reasons, last but not least politics - but the availability of tools and ease of use is also a criteria. Data modelers don't only grow in an environment of big business problems but also on university and by learning on their own. And the fertilizers there are good documentation, tutorials, examples (as in Terry's book), and available tools. It's partly a henn-and-egg situation: The more people use ORM, the more descriptions, examples, and tools there will be. Another reason contradicts your implicit assumption that ORM is better because you can do more with it: Sometimes it is better to be limited. In data modeling I'd guess it can also be useful to start with a list of possible entities and roles without any constraints or detailed connections.

Ken Evans:

It is my understanding that "the ORM features that are used an a model" are those features that are needed to adequately define the elementary facts in the universe of discourse"

That depends on how you "adequately" and "elementary". You can model almost any universe of discourse with a handful of very broad concepts or you can go into detail more and more. The more you dig, the more exceptions occur unless you have to model each single instance. It is my understanding that you can model the universe of discource in a continuum between one single entity "object" for everything and one entity for each single fact.

Maybe I should describe why I deal with ORM at all: my application is not software developement but management of metadata and information integration; I try to describe, analyze, compare, and develope metadata formats (some will also call them "ontologies" but I don't like this term). Some formats are very  broad with little constraints, some are very detailed, and they partly overlap. Some are defined by schemas, some are not. I need to describe different formats, show whether they share common concepts and rules, and how you can map them. For this task ORM is just one tool. In some cases euler diagrams and concept maps as promoted by J. Novak are fine, in some you can directly work with schema languages like XSD and OWL. Data Modeling languages like ORM are in between, that's why I need to formalize, exchange, and analyze them.

Ken Evans:

However, I'm curious to know how the "external algorithm" could uncover the "mistakes" and "pitfalls" without knowing about them in the first place.

There is some interesting research on automatic reasoning on ORM models, especially by Mustafa Jarrar and by Maria Keet.

jakob.voss:

so the practical impact of ORM2 in Linux environments is still very limited

 

I just wanted to make sure that you know that ORM-LITE/GanttPV is available on Linux and Macintosh in addition to Windows.

jakob.voss:

My current research includes transformation between different modeling languages (UML, EER, ORM2)

I am greatly interested in anything that you may have on ORM2 -> UML translation. The most complete algorithm I've seen to date is Peter Bollen's.

jakob.voss:

by the way: will you publish your parser as Free Software, Brian?

 

That is the plan.

jakob.voss:

I'd strongly bet that most features of ORM are rarely used in real world applications at all.

Interesting. My expectation would be just the opposite. There is very little in ORM that I would put into the "rarely used" category. Most of my "real world" data modeling experience occurred before I learned ORM; when I finally learned ORM I was impressed with how streamlined and practical the notation is.When I determined to implement a subset of ORM2 for ORM-LITE, I found very little that could be omitted.

Ken Evans:

It seems to me that the reason that ER and UML are used rather than ORM is down to one main thing: "marketing muscle".

 

I would have to agree with Ken on this. UML rose to dominances on the wings of a major news event. Three well-known, former competitors agreed to combine efforts and introduce what they believed could be a new industry standard. The publicity around their collaboration was astonishing. The need for a standard was well understood by the market place. It was an easy story for the media to explain. Tool vendors were faced with the need to announce compatibly or be left behind. Most of the tools and support came after the mind share had been captured.

ORM2 would have little chance of breaking in if it were just another UML. Ken's research suggests that ORM is enough better to be in a different category. Terry argues persuasively that UML is flawed enough to leave open an opportunity. But mind share remains the major obstacle to widespread use.

 

Jakob,

At my request, the University of Liverpool will not be publishing my dissertation. You should bear in mind that my "dissertation document" was the report of my research project that took nine months. During this time I studied hundreds of documents and conducted a survey and an experiment.

Regarding a "summarising paper" here are some extracts from my conclusion section:

The project was designed to investigate the hypothesis that "ORM based methods are at least 25% more effective than ER and UML" The literature study identified fundamental flaws in ER and UML which is evidence that supports the project hypothesis.  

The survey revealed much confusion about whether data modeling is a design or description activity. As ORM evolves, it should become more apparent that information modeling is an advanced design activity that requires highly skilled people. The survey results support the conclusions in Simsion (2007) that the notion that data modeling is a descriptive task is just a popular myth.

The experiment served to confirm the central hypothesis that ORM is at least 25% more effective than ER and UML. The results support the author's belief that ORM is a more effective approach than UML or ER. The experimental results show that ORM based methods take much less time and produce fewer defects. 

The results serve to confirm the author's opinion that the ambiguity in UML and ER mean that they are not suitable as techniques for specifying requirements.

Jakob: In data modeling I'd guess it can also be useful to start with a list of possible entities and roles without any constraints or detailed connections.
Many people seem to hold this view. However, as I see it, such a list does not have much meaning. The fundamental problem is that words (symbols) only have meaning when used within a context. (See language theory) We use the term "Universe of Discourse" (UoD) as a name for the context. So whatever you have wihin a given UoD provides the complete context for the meaning (semantics) of the terms and relationships within the UoD. I don't see how a collection of independent terms can be called anything other than "a collection of independent terms". 

Jakob: That depends on how you "adequately" and "elementary"
Within ORM the "atomic construct" is the elementary fact. (Defined on page 63 of Terry's Big Brown Book (BBB)). an elementary fact is one that "cannot be split into smaller facts without loosing information". My use of the term "adequately" means "in accordance with the procedures defined in the BBB".

Jakob: You can model almost any universe of discourse with a handful of very broad concepts or you can go into detail more and more.   
I disagree with this statement. A UoD is what you say it is. The UoD defines an information structure that can be used as a deductive logic system. If you only have  a few vaguely defined terms then you can't do much with it (except maybe convince yourself that you have done something useful when you haven't). Each of the different "models" whose existence you infer, are just that - different (and independent) models.

Jakob: The more you dig, the more exceptions occur unless you have to model each single instance.
ORM uses the concept of "elementary fact types" that you can think of as a template for a set of instances. (e.g. Person lives at Address)
Lots of people, lots of addresses - only one fact type. (and NO exceptions !)

Jakob:  It is my understanding that you can model the universe of discource in a continuum between one single entity "object" for everything and one entity for each single fact.
I don't agree with this notion. A UoD is what it says it is. Different UoD's are different UoD's. A "small UoD" is not the same as a "large UoD that happens to contain things with similar names and facts as appear in the small UoD". This approach is used in the IDEF0 method but it seems to me that the idea of a "continuum" is an illusion.

 

Jakob: management of metadata and information integration
For historical reasons, many people perceive ORM as a "data modeling tool" . Whilst it is true that ORM can be used for top quality data modeling, the reason for its excellence lies in the fact that it is a modeling language that is based on logic and set theory. So an object-role model is indeed a metamodel that can be used for information integration.

Jakob:  Data Modeling languages like ORM are in between
I disagree with this characterization of ORM because ORM is not a "data modeling language" (I prefer the term "information modeling language").
ORM is not "in-between" anything. It is a formal language that can be used to define any UoD without ambiguity.

Jakob: interesting research on automatic reasoning on ORM models, especially by Mustafa Jarrar and by Maria Keet.

 Yes - I have studied their work and discussed it with both of them.

Interesting term you use "automatic reasoning" . I don't see the "magic" in using the adjective "automated" to describe the term "reasoning".
The textbooks that i have read describe two types of "reasoning":  Deductive and Inductive. 
In deductive reasoning, the truth of the premises guarantees the truth of the conclusion.
On the other hand, inductive reasoning is about doing a form of "pattern matching" with "unstructured data".
Personally I have problems with the publicised notions of "inductive reasoning" because it seems to assume that you can "see something in nothing". 
But this is a tangential issue that I won't expand on in this post.    
Suffice to say that as I see it, the only difference between "reasoning" and "automated reasoning" is that someone has taken the trouble to code up their "reasoning algorithm" in a way that allows it to be processed by a computer.
My issues are with the "reasoning" bit not with the "automated" bit.

Mustapha and I disagree because (from memory) he seems to model the world in the same way that lexicographers work. For me, this seems to contradict the principle that "words only have meaning within a context"
Maria has done some excellent work with ORM. However, the basis of her approach is "mereology" founded by Stanislaw Leśniewski in the early 20th century. His approach was related to resolving problems such as Russell's Paradox about "sets that are members of themselves" As I understand it his approach deals with "parts and wholes"  http://encyclopedia2.thefreedictionary.com/Mereology 

According to the Encyclopaedia Britannica, "Leśniewski was openly critical of a pure formalism that would consider logic and mathematics as nothing more than a game of symbols." In this regard his notions seem to me to be in an "alternative universe" to that of mainstream logicians and mathematicians such as Leibniz who said "Let the symbols do the work".

It is my opinion that language itself is a technique used for communication that can be viewed as "nothing more than a game of symbols" so I don't believe in the basic precepts of mereology. The difference between ORM and many other languages is that ORM is a formal language that can be used to define a Universe of Discourse in a way that is unambiguous.

Ken