The ORM Foundation

See the picture below, diagrams 1 and 2. Shipments have Shipment lines. There are several kinds of shipments. So we could say that there are also several kinds of shipment lines: 'Production Shipment Line', 'Sales Shipment Line'. So on diagrams where the Sales domain is discussed it would be nice to talk about 'Sales Shipment Lines'.

How can this be solved with ORM? Something like in diagram 3? Or something with derivation rules?

If somebody can tell whether and where this is discussed in the Big Brown Book: please let me know!

Kind regards,

Jacob Vos

 Jacob,

Firstly, let me make some informal comments about some of the principles on which object-role modeling is based.
1. Each Obect-role model is based on "fact instances" which are then abstracted into the "fact types" that you see in an object-role model diagram.
2: Each fact type contains one or more object types and each object-type occupies a "hole" in a predicate.
 - The predicate is the "glue" that binds the object-types together

3: Each object-type represents a set of object instances.
4: We only use sub-types when we want to say something about each sub-type.
(i.e. Each sub-type is an object type that must participate in a fact type - NORMA does not enforce this but it is good practice.)

Now to comment on your diagrams:
It is not clear to me what fact instances you are trying to represent.
It would help if you could:
* Explain what you mean by: "shipment", "shipment line", "production shipment"and "sales shipment"
* Add at least one fact type to each of your sub-types "production shipment"and "sales shipment"

Also:
* You have not used a reference mode for any of your object types - is this intentional?
* Object-type names should not include spaces.- If you tried to use your formulation in NORMA it would not work.
* You have not added any readings - the readings are the predicates - without predicates the fact types don't have much meaning.

Please will you clarify the problem you are trying to solve by responding to these points.

Thanks

Ken 

Jacob has shared a partial model. I don't think it's necessary to criticise him for the things he deliberately omitted (except the readings, though they're still not necessary to answer his question). You address everything except his question.

Ken Evans:

* Object-type names should not include spaces.- If you tried to use your formulation in NORMA it would not work.

I don't believe this is true. In fact, I make a point of using space-separated words, and even spent a couple of weeks adding support for this into CQL, a couple of years back (it makes the parse harder but I think it was worth it). NORMA just crunches the spaces out - as do the CQL generators for languages like SQL, Ruby, etc that don't support spaces.

Jacob, if you want to use a contingent role name (for fact instances where the player is a subtype), that's like using a different reading. You could add a derived fact type for each subtype, whose instances include only those relevant from the supertype. Then you can add whatever reading and/or role name you wish to use for this derived fact type

 Hi Clifford,

My intended message was: "I can't answer your question because I don't understand what you are trying to say in your models."

So my earlier post was partially aimed at understanding the kinds of instances that Jacob intended his object-types to represent.
This would have helped me to understand the Universe of Discourse that Jacob was trying to represent without my resorting to guesswork.

By guesswork, I suggest the following diagram as a "solution" to the representational problem that my guesswork tells me is the problem that Jacob is trying to solve.

Is it in the BBB? - Well yes. Its in the bit that explains how to use subtypes. 

Regarding spaces in object-type names:
It is true that you can edit names within the object-types to include spaces.
However, NORMA's fact editor throws an error if you try to enter an object-type name that includes spaces.
   

Hi Ken and Clifford,

Thank you for your replies. @Ken: I use ORM for about 8 years (and am very satisfied about it!) and knows very well the things you wrote. However I only gave the information that I thought it's enough for ORM specialist ;-)

@Cliffor: See the picture below: is this what you mean? I haven't a good feeling about it, because the label 'sales shipment line' has in fact two definitions.

@Ken: Thank you for your diagram. However there is no such relation between a Sales Shipment and a Sales Order as your diagrams suggests. A sales shipment is meant to deliver sold goods. Sold goods are laid down in sales order lines. Sales order lines of different sales orders may be 'used' in one sales shipment. For this a sales shipment has lines, and each such line is related to one sales order line mentioned.

Jacob

 Jacob,

Thanks, but I find your explanation to be very confusing.
Putting the word "line" in bold does not help anyone to understand what it means.
That is why I asked you for an explanation of the object-types in the first place.

So what is a  "line"?
Is it a "line item" on an order form?
- in which case it could be anything that has been sold to a customer and on one order form "line 3" could be a washing machine whereas on another form "line 3" could be a screwdriver.

Or is a "line" something to do with the "lines" that a company sells?
- in which case "Sales line 24" would always be something like "Brush type number 51 in blue".

Or is a "line" something else?

Such problems are disambiguated by giving:
a) an informal description of the object type.
b) examples of instances of an object type.

I'm not a mind reader so it would be helpful if you clarify your universe of discourse in the usual way.

Thanks

Ken

Hi Jacob,

The focus in other answers (including yours) is to rederive the primary fact type (between Shipment Line and Shipment) for each of the subtypes of Shipment. However, your initial description says you want a 'Sales Shipment Line' object type that you can talk about in other Sales diagrams. For me, this indicates that you want a derived subtype, not a derived fact type. Given that the constraint pattern indicates a shipment is know for every shipment line, and it is known whether that shipment is a sales shipment, creating a derived subtype for 'Sales Shipment Line' seems like the natural way to go.

You can do this textual in the open source version, or formally with the pro version (although the pro version doesn't do any physical mapping of the rule yet). So, Each Sales Shipment Line is by definition some Shipment Line that is of a Shipment that is some Sales Shipment.

-Matt

PS The NORMA fact editor can enter object type names with spaces in them using [square brackets] around the name. What is not possible right now in the fact editor is to add capitalized words that are part of the predicate text and not treated as object type names. You can do this with the reading editor, however.

Personally, I prefer to use PascalCasing for names. While these are easier to use in the tool, they can also be less readable for domain experts who are reading the verbalizations, so you can split them up automatically for verbalization using the ObjectTypeNameDisplay in the Verbalization section of the ORM Designer options page (available through Tools/Options).