To group or not to group

Earlier in the projects history it was decided not to use role groups for the Observables model, mainly because at the time, the model was proposed to include nested definitions more specific than what role grouping admits. Also, the nesting patterns using role groups for procedures and findings (i.e. having more than one "part" of the procedure or more than one "condition" for the finding) does not apply to observables. There will only ever be one kind of quality and observation procedure referred to by one observable.

Below is an example of the relationship table for an observable created using SnoOwl from UNMC:

id	effectiveTime	active	moduleId	sourceId	destinationId	relationshipGroup	typeId	characteristicTypeId	modifierId
389446341000004000		1	900000000000207000	799635351000004000	117362005	0	370132008	900000000000225000	900000000000451000
154043481000004000		1	900000000000207000	799635351000004000	64195000	0	704320005	900000000000011000	900000000000451000
113689121000004000		1	900000000000207000	799635351000004000	443412009	0	116680003	900000000000011000	900000000000451000
953865841000004000		1	900000000000207000	799635351000004000	367651003	0	704319004	900000000000011000	900000000000451000
978593911000004000		1	900000000000207000	799635351000004000	441652008	0	704327008	900000000000011000	900000000000451000
326682591000004000		1	900000000000207000	799635351000004000	776042991000004000	0	9216841000004100	900000000000011000	900000000000451000
557253841000004000		1	900000000000207000	799635351000004000	118536000	0	704318007	900000000000011000	900000000000451000
326573721000004000		1	900000000000207000	799635351000004000	123029007	0	370134009	900000000000011000	900000000000451000
232992231000004000		1	900000000000207000	799635351000004000	258066000	0	246501002	900000000000011000	900000000000451000

As can be seen, all relationship groups (role groups) are 0. Most attributes use to define observables are exclusive to the observables model, with the exception of 246093002 | Component (attribute) |. The same SnoOwl tool outputs observables concepts as below:

The RF2-to-OWL script provided with the international release of SNOMED CT role groups everything that isn't explicitly marked as "never grouped" by hard coding the list of attributes not to be "automagically" put into role groups. All other attributes are currently put inside a role group, even if relationshipGroup equals 0 in the RF2 file. Currently these "never grouped" attributes are:

$nevergrouped{"123005000"} = "T"; # part-of is never grouped
$nevergrouped{"272741003"} = "T"; # laterality is never grouped
$nevergrouped{"127489000"} = "T"; # has-active-ingredient is never grouped
$nevergrouped{"411116001"} = "T"; # has-dose-form is never grouped

There are three possible solutions:

Always role group all observables into one group. + easy to achieve, - no straightforward corresponding semantics (as for findings and procedures)
Make observables use two role groups, one for target of observation (quality, disposition, function) and one for the observation procedure, + almost as easy, - interim solution, "semi-straightforward" semantics only
Create a new COMPONENT-like attribute exclusive to the observables model and add all observables attributes to the "never grouped" list. + easy to achieve (see @Former user (Deleted)'s comment), - lack of re-use between models (procedures and observables)
Remove role groups from evaluation procedures (which should be observables anyway?), - more invasive solution (~9000 concepts, 15 with explicit, but still only 1, role group)
Add rules to OWL generation software (or similar) which distinguishes between observables and procedures, - more complex software --> harder to implement
[added 2016-10-12 ] Remove implicit role grouping, as described in comment below.