Another way to think about the title is semantics versus database/UML/... renderings.

For me, "semantics" is not the structure or representation of data (property names, types, …) but the meanings, usages and conceptual hierarchies.  An example is the concept of a “dog” – which is a living entity, a mammal, a pet, maybe a food supply, or the particular detailed anatomy of a dog.  At different points in time, you might need each of the different contexts – or you may never care about some of them. “Dog” can be represented by the words, "dog", "canine", "chien", a petroglyph, … The different usages and contexts are how you understand a model.  But, traditionally in software development, we model only the single representation that we need, with one (usually implicit) meaning and intended usage.   

Another example of the problem is a 1:M relationship.  What does the relationship “mean” – not how is it represented? What can you infer as to dependencies, implications, lifetimes, …?   The rendering may be a pointer to the 1 side of the relationship, or to the many side, or both (if there is the possibility of discrepancies).  It may be two individual pointers, or one relationship entity.  The problem is that you may not be able to define the representation that you need until you know the environment.  Or, the representation that you need changes over time.  Different environments may require different encodings/renderings – but the same semantics and meaning apply. 

(IMHO) Representation should be secondary – semantics and context are pretty critical.  In general, capturing semantics and understanding context are terrible problems – but in the limited contexts of a business, coupled with the requirement that a business have clear vocabularies, rules, etc. – we can reduce the complexity greatly.

To further complicate things, there is the problem that concepts/semantics combine to form larger meanings – as in sentences and texts.  Without meta-data, abstraction, contextual definitions, you can’t determine these larger meanings or infer new information.  This is where semantic computing comes into the picture. 

At the end of the day, if the goal is to write a database for a specific usage, a developer figures out the semantics, context, …  in their heads and the database tables are the resultant rendering.  But, to really understand the database, you have to know what the designer was thinking! 

If your goal is to document an environment and find ambiguities and inconsistencies – or to merge multiple environments – then you better have more information than the representation.

Andrea