I would like to recommend that Source Ranking be added to newFamilySearch. Many submissions include sources such as "Downloaded from a GEDCOM" or "Downloaded from Ancestral File" or "Personal Knowlege". I would like there to be a way for patrons to vote or rank different sources so that sources like a "Death Certificate" could be ranked higher than "Uncle Bill said so".

Gary TurnerIf you haven't already, please take a moment to review our newCode of Conduct

Not having played with the new one yet - why would this be important? If a group of sources all indicate the same data, why does the listing order or ranking order of the sources matter? Or do you mean than you're effectively trying to apply a "weight" to conflicting information to change what shows as the default?

In connection with the API that is supposed to be available once the new FamilySearch goes live for real, another thing I'd like to see is a published algorithm for translating between the PIDs (KH34-RG9D-S, for example) and the manid and womanid values used in the navigation URLs in the Family Group Record mode (and perhaps other modes). There are lots of ways it would be helpful to be able to go between the two forms if there is a way to convert between them. Of course, I'm submitting the suggestion through official "Send Us Feedback" channels.

gblack wrote:Not having played with the new one yet - why would this be important? If a group of sources all indicate the same data, why does the listing order or ranking order of the sources matter? Or do you mean than you're effectively trying to apply a "weight" to conflicting information to change what shows as the default?

I think some sources, like a federal census, should have more weight than something like word of mouth. I'm not saying that word of mouth is bad but usually a census is more correct.

gblack wrote:Not having played with the new one yet - why would this be important? If a group of sources all indicate the same data, why does the listing order or ranking order of the sources matter? Or do you mean than you're effectively trying to apply a "weight" to conflicting information to change what shows as the default?

The purpose of ranking sources would be to make sure that the most accurate information is what is displayed. Here is an example from a Beta2 screen. Notice 3 different versions of James Swallow. One has a different Spelling of Swallow, one has a middle initial and the rest are the same. FYI this screen is for combining possible matches. Those on the left have already been combined the one on the right is the possible match. When you look at the sources screen it says some sources are LDS Chruch membership records, Ancestral File Downloads, Family Records, and a lot with no sources at all. There were about 40 contribuitors to this name. There are also different submissions for the birth place and the childrens info.

Gary TurnerIf you haven't already, please take a moment to review our newCode of Conduct

Another suggestion I just made through "Send Us Feedback" is to consider an official, sanctioned project to do merging and cleanup of Biblical generations. A check in the beta system of people from Adam and Eve to the 12 sons of Jacob/Israel seems to show a huge number of duplicates back this far. With the enormous number of people who link or will eventually link to these ancestors, I hate to think of the (bigger) mess a bunch of fumble-fingered folks like myself could make of these records.

I would like a versioning system for FH somewhat like CVS or SVN. Often, I have branches of FH that I am exploring, but that I do not want to keep in my master copy. I end up maintaining multiple files and manually trying to resolve differences.

This would be the perfect situation for "branching" my geneology, much like you would branch a code tree. I would use a code versioning system, but they dont know how to talk GEDCOM, and I have not been motivated to teach them how.

My guess is something along the lines of version/configuration management will end up happening, probably through external software using the new FamilySearch API. I would anticipate it will become common to keep a local copy of some data to look for changes someone else may have recently made. I think it will be interesting to see what usage patterns develop.

The Earl wrote:I would like a versioning system for FH somewhat like CVS or SVN. Often, I have branches of FH that I am exploring, but that I do not want to keep in my master copy. I end up maintaining multiple files and manually trying to resolve differences.

This would be the perfect situation for "branching" my geneology, much like you would branch a code tree. I would use a code versioning system, but they dont know how to talk GEDCOM, and I have not been motivated to teach them how.

ThanksBarrie

This is an interesting idea. I work quite a bit with versioning systems and application development. I've never thought to apply the principles to genealogy data. That could be pretty slick.

Hope I'm in the right thread. Although I'd love to see all kinds of multimedia features in NFS I also would want to make sure that data is secure and possibly restrict access somehow. Has there been consideration of what source document images will be made public and which can be marked private by users of NFS? Is documentation going to be downloadable or only linkable - useable offline or only available online? For example, I'd like to upload pictures or vital records of ancestors; however, I wouldn't want them to fall into unscrupulous hands. Is there some sort of user-level security that could be implemented so that other users could be aware of source images in another users submission but in order to gain access they have to contact them/show relationship to the family line? Even then who knows if the person is trustworthy? Perhaps some sort of ranking system for the user submission - if they submit more source information they are rated as a more trustworthy source of information? I just wouldn't want to see a problem where the source documentation/images are used to steal an identity or something. Of course if the data is secured that could be a method of reducing the problem of identity theft - we would just have to create the identity of each individual as completely as possible so that if anyone else tried to use that identity a red-flag would be raised. Oh boy, then I bet the state/fed would love to have that database...<chasing my tail in circles> Maybe the system should require user registration or a submission of x generations with source materials to gain access to search features? Just some thoughts...