What is the best way to enter facts where an object is expressed in terms of measurement (and that unit type is not in the dropdown list for RefMode)? For example:
House(addr) has Size(sqr_ft), Where the house size (some range of values in these units), might be referenced elsewhere in the model (such as a house of less than 1500 sqr_ft being eligible for special financing).
Do the selections in the dropdown list have any effect other than in the verbalization and automatic selection of an appropriate datatype? Are there any logical effcts in the model itself? I'm taking it that the list is just a convienece for the modeler, using a RefMode not in the list has no other effects. Thanks. BRN..
[Some of this may change soon, we'll be revisiting the reference mode pattern in about a month to enable things like a collapsed form for an entity type reference mode and formal relationships between convertible measurements (ft and m would both be units of length)]
To add a refmode to the list:
1) Open the 'ORM Reference Mode Editor' tool window
2) Expand the 'Custom Reference Modes' branch and set the name for a new reference mode
3) Change its reference mode kind (in this case to UnitBased)
There is currently no way to set a default data type for a custom reference mode. Note that you can use the 'ORM Designer' of the Tools/Options dialog to change the default data type for any new value type.
Reference modes are determined based on a pattern match between the name of EntityType and the name of the ValueType RolePlayer of a single-role internal preferred identifier. The reference mode association is derived, not stored, and written to the xml with a leading _ on the property (leading _ attributes are ignored by the loader). Change the pattern for a refmode (or the pattern for the refmode kind on intrinsic refmodes) will change the name of the associated value types wherever the old pattern is matched.
Whether a refmode is expanded or collapsed is purely a UI setting, it does not change the underlying object model.
[Read the first caveat before getting two attached to the current system]
Thanks for the info, and headsup on pending changes. I recall that getting a handle on what was meant by, and how to use a primary reference mode, was one of the tough things to 'get' when I first started with Asymetrix Infomodeler. On the one hand, it's just a shorthand version of an elementry fact type; on the other, the choice of that fact type has a singularly profound impact on the model, and the resulting data structure.
Having a dropdown list makes it easier to assign a commonly used reference, like name or id, but can make things more confusing for people new to the proccess. For one thing, the list might be better if a default data type associated with the PRM was displayed at the same time; that would help in the choice between say 'Name' (variable length character), or 'ID' (Auto incrementing numeric). Grouping the listings into generic dimensions, as you mentioned, should help too - maybe with futher drilling down showing the data type, as mentioned above.
Having a list also seems to encourage the use of a simple PRM over a composite mode, though that may not be the best choice. Should the modeler choose one method or the other at the start - projecting the implications and assessing which would be best - or should it be easier to go with a more natural and expressive (maybe) composite PRM, then change that to a simple PRM before generating a schema?
How much does all this effect the flow of putting togther a conceptual model? Making good choices for the PRM is very important, but at what point does the choice have to be made in order for the methodology to work effectively? Can a modeler start dropping Object Types on to the model; start getting the connecting facts established; and only later spend time getting the PRM right for each Entity? Maybe that depends on the use of sample data? It would be tough to use sample data without having chosen a PRM.
Lot's of good points, and we'll consider the feedback as we put some of the new pieces together.
As for when to set the PRM, one piece of feedback we've gotten is that a number of errors are visible before people want to deal with them conceptually. A mechanism to show/hide different classes of errors (down to the individual error level) will be introduced, although I didn't have any student bite on the project this quarter. Although the error display was designed to be non-invasive and can be used as an integral part of the development experience (see PS comment), not everyone likes seeing all of the errors up front. Specifically, the DataTypeNotSpecified and EntityTypeRequiresPreferredIdentifier errors are very noticeable and some argue not important at early modeling stages, so it would be nice to not show these. Obviously, we won't successfully generate until they're gone, however.
As for sample data, unlike Visio, the values for FactType and EntityType population must be pulled from existing ValueType values. Sample population is not limited to the local FactType. The only way to do this is on EntityTypes is with a preferred identifier (complex or simple). This means that getting some primary reference scheme up front is necessary for sample population. In the long run, this will let use show full tables of sample data, not just samples for isolated fact types, and will also let use seed your DB and/or provide an initial sample population from the model. We're also looking at doing counterexamples for constraints, which would let us generate unit tests to verify that the correct DB protection is in place to keep invalid data out of the DB.
PS On leveraging validation errors to enhance the editing experience: Double-clicking an item that has validation errors will go through the list of errors in the same order as the validation error context menu and activate the first activatable error (not all errors activate, but a lot of them do). For example, if you drop on a new binary FactType, try the following sequence to clear up the four initial errors:
1) Double-click the FactType border region (the cursor will show as the move cursor). This will activate the reading editor and put it in edit mode so you can enter your reading.
2) Double-click a second time to add an internal uniqueness constraint and enter edit mode for that constraint. A second double-click on either of the roles will add the constraint to the role (to add both, click on the first, double-click on the second). At this point, the FactType error marker (the border region) will clear up.
3) Double-click the first role to activate the 'RolePlayerRequired' error and click on an ObjectType.
4) Repeat 4 for the opposite role.