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.
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).