The Entity Framework is pretty big, so when the Entity Framework team talks about things internally we tend to use jargon to increase communication 'bandwidth'.

Unfortunately sometimes we let this Jargon slip into our APIs and communication.

Now jargon is fine if you are in on the secret, but if not, its just straight out confusing.

So lets outline some of the more common pieces of Entity Framework Jargon and what they mean:

1. EF
   This one is easy, Entity Framework!
2. EDM / CSDL / Conceptual Model / Model
   All of these mean basically the same thing. CSDL is our XML format for describing an Entity Data Model or EDM. And occasionally when trying to use less Jargon and be a little more accessible, we will say Conceptual Model or even just Model. We are very conscious of the confusion this has caused, and are doing our best not to make the same mistakes again.
3. MetadataWorkspace
   This is the holder of all the metadata that the Entity Framework uses to reason about your database, your model, your CLR classes and the various mappings between them. The easiest way to get hold of one is via the MetadataWorkspace property hanging directly off the ObjectContext.
4. C-Space, S-Space, O-Space
   The Entity Framework's MetadataWorkspace stores its metadata in "spaces". So in order to use our Metadata APIs you need to understand what these spaces mean:
1. C-Space. This where the metadata about your conceptual model lives, it is loaded from the CSDL.
2. S-Space. This is where metadata about the database lives, it is loaded from the SSDL.
3. CS-Space. This is where mapping information lives, yes you guess it it is loaded from the MSL.
4. O-Space. This is the Object Space, or CLR space. The O-Space is where metadata about the CLR types that map to your conceptual model is found. In .NET 3.5 SP1 this is loaded from the Entity Framewok attributes in the CLR types.
5. OC-Space. This is where EF holds the mapping between you conceptual model (C-Space) and the CLR objects (O-Space).
5. O-C Mapping
   When we talk about "mapping" we are usually talking about the mapping between the conceptual model and the database, which where most of the flexibility is. However there is another type of mapping in the EF, O-C Mapping, which is between the CLR objects (O-Space) and the Conceptual Model (C-Space). In .NET 3.5 SP1 our O-C mapping capabilities are very limited, but in .NET 4.0 because we support POCO our capabilities are significantly better, but there is still a long way to go...
6. Relationship Fix-up
   Relationship Fix-up is the process by which the EF, links related Entities together. For example fix-up will set the "Customer" property of an Order when a known to be related Customer is materialized from the database. Once you understand fix-up you can leverage it to do all sorts of interesting things.
7. Relationship Span
   If you've read about independent associations and foreign key associations you know that in .NET 3.5 SP1 foreign keys are not structurally part of the Entity. Strictly speaking this means retrieving an Entity from the database shouldn't bring back the foreign key values. In practice it turns out not having these FK values in memory causes all sorts of usability problems (as discussed in Tip7 and Tip 9). So to avoid these problems the EF returns FKs with the entity anyway, and yes you guessed it, this feature is called relationship span.
8. CQTs and CCTs
   Canonical Query Trees and Canonical Command Trees are what the entity framework sends to the database providers to describe the commands it wishes to execute in a provider agnostic (or canonical) way. The trees themselves are made up of a set of common operators and functions that we expect all database providers to support. The provider's job is to translates these provider agnostic trees into native SQL commands.
9. POCO
   The acronym POCO or Plain Old CLR Objects is not an invention of the Entity Framework team, but  we've definitely run with it! The idea is that you can persist classes that have absolutely no dependencies (like base classes, interfaces or attributes) on the Entity Framework itself. This has been one of the major focuses of our team for .NET 4.0.

One of the things I've learned since joining Microsoft, is that if you have lots of people talking to customers, you have to be very explicit about the terms you introduce. If you don't ill-thought and confusing internal jargon has a habit of gaining a foot hold with customers, and misunderstanding will often ensue!

That said let me know if you can think of anymore Jargon and I'll add it to this list.