-
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
Use Confidence Level instead of Preferred flag #176
Comments
+1 |
Exactly so :) |
So does this proposal effectively boil down to removing the preferred flag? It's intent doesn't have anything to do with analysis. It's there to tell software which one should be displayed in e.g. a summary view or a list view. |
Yes and make the confidence level numeric instead of EE word categories but also see discussions at the end of #135 about "evidence" rather than "confidence".
Explain to me how a researcher can "prefer" something that they themselves believe has less evidence than a competing theory? |
You'd have to be able to separate which name you'd like to see when the person is displayed with other persons from which name you think is most correct. I'm browsing my pedigree. I know the most correct name of my grandpa is "Emma Joy Gledhill", but the name in my pedigree I'd like to see is "Emma Gledhill". |
This is UI stuff .... If you are talking about interworking of different applications by the same researcher then I see your point - any quirks you have in one app you want to see in the other. But if we are talking about exchange of data between different researchers (agents if you like) then you would be misleading readers if your UI only showed them the "preferred" item which was something you just picked out of the air. |
You have a grandfather name Emma? ;-)
So let's call it "displayValue" or something instead of "preferred". |
LOL! Well spotted @jralls ... of course if we'd being using evidence @stoicflame then you would have spotted this ;)
If we must but I would still argue that this is strange logic ... why are we assuming that an app. can only display one name/birth/fact etc? Surely any decent app worth it's salt will display them all and/or allow the user to sort according to a variety of factors depending on what they are trying to do at the time. |
Not always. I'm sure you can think of plenty of reports, charts, and displays where you wouldn't want all of everyone's AKAs displayed. Yes, it's a presentation-layer preference item, not of great importance to the genealogical evidence being shared. More of a convenience to a user who's converting her data between programs. |
Yes but that's UI and surely we're not going to define every UI requirement here!?! |
Like I said, not of great importance, more of a convenience to the user. |
I don't see why you would need a "displayValue" or "preferred" tag on a given list item. There is already enough data to find which element to display:
|
+1. I totally agree. |
Closed with 38091ee |
The "Preferred" flag assumes that there is a single preference but does not allow for:
(a) instances where conflicting hypotheses may be of equal validity (and hence need further research to prove one way or another) e.g. two different Birth dates.
(b) instances where different hypotheses can co-exist without needing resolution (e.g. two different Names or Residences)
If instead of using Preferred we use a numeric value then the different instances can be ordered according to their weight - the one(s) with the highest value being "Preferred".
To take this a step further, if instead of supplying a separate/different number we used the confidence level of the Attribution then we have a neat automatic way of seeing preferences without the need for further data entry.
[This does assume that the Confidence Level is to be treated as a numeric value with negatives as well as positives - which is needed anyway to account for negative proofs - see #127]
The text was updated successfully, but these errors were encountered: