When the Pathway's work was done, we defined a pathway (no pun intended) to expressing more complex rules for selecting pathway components from an array of candidates that go beyond the current "simple count rule". Since we were not prepared at that time to pursue how these more complex models should be modeled, the ceterms:alternativeRuleSet property pointing to such rules was defined as "unstable". We also made the decision that we'd define a ceterms:requiredNumber property on ceterms:ComponentCondition to handle the widely used "simple count rule".
The modeling of more complex rules is something we should approach cautiously and with input from additional technical experts beyond our core team which to me means a workgroup. I emphasize technical experts because the nature of the problem is clear; a solution that does not lead to a proliferation of properties is elusive. While I am sure we'll hear from some that the problem is too complex to solve in data, I do not think that is the case. There is no doubt that complexity presents thorny issues with regard to displays etc. and perhaps even search, but I do not think that we'll have a fully useful Pathway specification if it drops out the complexity of the original data.
I did some initial thinking months ago about a suggestive general approach illustrated in the following diagram. The approach relies a bit on how the expression of complex rules are handled in the ODRL (Open Data Rights Language) specification. It's intended to be the beginning of a more structured work group conversation. Until this happens, I think we need to place a moratorium on additional properties in the service of pathway rules.
Related to #796
When the Pathway's work was done, we defined a pathway (no pun intended) to expressing more complex rules for selecting pathway components from an array of candidates that go beyond the current "simple count rule". Since we were not prepared at that time to pursue how these more complex models should be modeled, the ceterms:alternativeRuleSet property pointing to such rules was defined as "unstable". We also made the decision that we'd define a ceterms:requiredNumber property on ceterms:ComponentCondition to handle the widely used "simple count rule".
The modeling of more complex rules is something we should approach cautiously and with input from additional technical experts beyond our core team which to me means a workgroup. I emphasize technical experts because the nature of the problem is clear; a solution that does not lead to a proliferation of properties is elusive. While I am sure we'll hear from some that the problem is too complex to solve in data, I do not think that is the case. There is no doubt that complexity presents thorny issues with regard to displays etc. and perhaps even search, but I do not think that we'll have a fully useful Pathway specification if it drops out the complexity of the original data.
I did some initial thinking months ago about a suggestive general approach illustrated in the following diagram. The approach relies a bit on how the expression of complex rules are handled in the ODRL (Open Data Rights Language) specification. It's intended to be the beginning of a more structured work group conversation. Until this happens, I think we need to place a moratorium on additional properties in the service of pathway rules.
Related to #796