-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal to refactor "extracted" flag to accommodate additional states #251
Conversation
+1 |
1 similar comment
+1 |
Initially, I thought I agreed with this proposal. However, I was unhappy with the proposed property name. To me, we are not talking about research states. It is true that research can be in a hypothetical (or working) state or in an accepted (or proven) state, but what does it mean to have research in an extracted state? Thus, my search for a better property name....which I have yet to discover. A researcher might create a conclusional
As I have thought about this further, however, I am inclined to revert toward only two
Right now, the model distinguishes these two cases via the state of the In the case of a hypothesis, perhaps we can talk about research state. I could say my hypothesis is a working or an accepted hypothesis. But consider the following use case: I have a I know the person exists, but not every aspect of the person ought to be “accepted”. But perhaps I am personally “done” working on it, so it is “acceptable” to me. Using the proposed scheme—a Probably what I would really wish for If instead we make the scheme I still wonder if we would be better off turning |
I think research state is an important idea but I think it should apply to the specific work subset (e.x. a single source analysis, a GPS analyisis, Final Conclusions) including both the Document, the extracted conclusions, and source list. I have generally been thinking of an N-Tier approach where there are 3 tier in the common case. T1: Single Source Analysis, T2: GPS Analysis using T1, T3: Conclusion space as the union of all T2. I see 3 research states:
When you create a new source analysis or GPS analysis it should be in the started state. If there is NOT enough information to make conclusions then the user sets it to Unresolved (Forever or until more evidence turns up). If there is enough evidence to make conclusions then the user set the state to Completed when finished with the work subset. Then at anytime if a work subset is modified - then it and all other "things" that depend on it shall be state changed to New_Evidence_Requires_Re_Evaluation_Of_The_Analysis by the system. New_Evidence_Requires_Re_Evaluation_Of_The_Analysis may not be an actual state, but it is a least a theoretical state that must be possible, either by it being explicit or by modification timestamp analysis of the dependency chain. An analysis is only valid if it is completed after all work products that it depends on. |
Okay, after the explanations and comments submitted by @thomast73 and @nilsbrummond, I'm going to back off this proposal. @thomast73 offered a reasonable argument to keep the notion of "extracted" separate from the notion of "research states". At this point, I have no intention of proposing the formalization of the concept of research states to the first version of the conceptual model because:
|
In an effort to identify potential backwards-incompatible changes that may need to be applied in preparation for our milestone 1 release, I keyed in on the
extracted
flag. The intent of theextracted
flag is to identify a conclusion as "extracted" from a single source. I think this is an important state to identify, but I'm wondering if there are more than just two "states" of a conclusion--I'm thinking there are three: "extracted," "hypothetical" (the conclusion is working hypothesis), and "accepted" (the conclusion has been formally accepted based on the evidence we have, and there should be a proof statement in the form of an analysis document).This pull request is a proposal to refactor the
extracted
flag to be a property namedresearchState
. The data type of theresearchState
property is an enumerated value. Section 4 I renamed to be "Research States" and now includes (in addition to the "extracted conclusion" constraints) the "known research states" enumeration, which is defined as follows:http://gedcomx.org/Extracted
http://gedcomx.org/Hypothetical
http://gedcomx.org/Accepted
Comments are welcome.