Skip to content
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

Closed
EssyGreen opened this issue Jun 28, 2012 · 14 comments
Closed

Use Confidence Level instead of Preferred flag #176

EssyGreen opened this issue Jun 28, 2012 · 14 comments

Comments

@EssyGreen
Copy link

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]

@daveyse
Copy link
Contributor

daveyse commented Jun 28, 2012

+1
I think this would be a great improvement in that the confidence level of one hypothesis may be increased (or decreased) with further evidence, and would naturally and automatically percolate it to be the Preferred (or demoted from the Preferred). This would also allow multiple hypotheses to concurrently earn the title of "Preferred".

@EssyGreen
Copy link
Author

Exactly so :)

@stoicflame
Copy link
Member

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.

@EssyGreen
Copy link
Author

So does this proposal effectively boil down to removing the preferred flag?

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".

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.

Explain to me how a researcher can "prefer" something that they themselves believe has less evidence than a competing theory?

@stoicflame
Copy link
Member

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".

@EssyGreen
Copy link
Author

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 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.

@jralls
Copy link
Contributor

jralls commented Jul 12, 2012

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".

You have a grandfather name Emma? ;-)

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.

So let's call it "displayValue" or something instead of "preferred".

@EssyGreen
Copy link
Author

I know the most correct name of my grandpa is "Emma Joy Gledhill"

You have a grandfather name Emma? ;-)

LOL! Well spotted @jralls ... of course if we'd being using evidence @stoicflame then you would have spotted this ;)

So let's call it "displayValue" or something instead of "preferred".

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.

@jralls
Copy link
Contributor

jralls commented Jul 13, 2012

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.

@EssyGreen
Copy link
Author

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 but that's UI and surely we're not going to define every UI requirement here!?!

@jralls
Copy link
Contributor

jralls commented Jul 13, 2012

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.

@mikkelee
Copy link

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:

  • Since lists are ordered, the user/software can choose to always display the first element from a given list, and save the subsequent elements for detail views. This of course requires the spec to emphasize that list order is meaningful.
  • The user/software can inspect the confidence levels (which I definitely agree on including with conclusions) on each element, using the element with the highest confidence for display, and the rest for detail views. If there are multiple with the same confidence level, either pick one or use list order as above.

@EssyGreen
Copy link
Author

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.

@stoicflame
Copy link
Member

Closed with 38091ee

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants