WeRelate talk:Suggestions/Assertions

Previous discussion moved from suggestion page proper:

A recent Watercooler discussion again brought up the idea that we would to be able to add some non-traditional facts. Ideally, these facts would be useful both for a browsing human user but also (eventually) for various software operations such as GEDCOM upload and consistency checks. The primary example in the current discussion is a desire to explicitly note that the parents of a person are not known - or at least not with certainty - based on current research. If this information were recognizable by the system, then GEDCOM uploads could decline to attach parents. If a parent were to be added - a future consistency check program could note that there is both a fact claiming parents aren't known but an attached set of parents.

Instead of the single case under discussion, it seems that it would be more wise to try to deal with a range of assertions that can help us to add useful facts in standard ways. Here are a few possibilities:

(moved to a common group at the bottom)

Almost certainly there are others. We should get as many as we can imagine and then - perhaps - prune that list back to those that we would really like to use.

While the templates for such facts could, in principle, appear anyway. I think they make the most sense as "other" fact events. --jrm03063 23:03, 21 December 2012 (EST)

Here's another contribution from janiejac - errors that get traction from being published somewhere and not sufficiently refuted until later on. I've been working to annotate Savage off and on since early this year, and have 54 specific errors noted. So a nice way to explicitly declare information that was once accepted but subsequently debunked would be helpful.

{snipped old version of list}

Another revision/update of the potential assertion template list.

Comments copied from Watercooler "Handling of parentage contenders" discussion [5 January 2013]

The suggestions for flagging the problem with a template seems good to me. Maybe someday a software enhancement can use the flag to limit linking by GEDCOM upload, merging, or whatever. Even before that, though, I think a visible notification on the person page can be helpful in alerting people to the situation. This should reduce the attempts to add parents without adding supporting evidence but will not eliminate them, so we can expect to have to remove unsupported parents from time to time in spite of using such a template.

Towards this end, I have set up a draft template at Template:Parents Unknown. Please feel free to improve it, or discuss changes on the talk page there (or, of course, discuss the advisability of having it at all right here). --Robert.shaw 17:56, 21 December 2012 (EST)

Thanks for pushing the question. I agree that we should only link a parent, spouse, family, etc., when there's a very strong case to do so. Perhaps not perfect, but strong. If there are contenders, then we should indicate as much in a disputed lineages section on the person page and respective family pages (even though the text is duplicated - you can write it generically and often copy paste.

I want to be a little more careful on how we do the information/added fact templates. We want to allow for the description of a number of situations, and do so in a way that is easy to find and recognize (by humans AND software) later on. Let's get a full list of the things we know we want to assert. Then we can decide whether each one is a template on its own - or whether we can do this as a smaller number of templates with parameters. Even if there are multiple templates - we'll want to do them all in a similar manner. We should probably move that discussion somewhere else...I'm writing a suggestion called "assertions". --jrm03063 22:54, 21 December 2012 (EST)

You are speaking of missing info or known factual info; what about known errors? In my Jackson line there is a known error attributing the wrong parent to the wife of a Revolutionary soldier. The error was accepted by the DAR for years and so researchers accepted it. The DAR was notified and now does not accept applications based on that error. But numerous genealogy trees using that info are still floating around. I can describe the problem on her talk page but that wouldn't stop erroneous GEDCOM uploads. How could a template be worded to refuse to upload erroneous parental information? And how many folks would have to agree that it is erroneous before using such a template? --janiejac 15:12, 22 December 2012 (EST)

Very true. I'm not sure about handling it automatically, but that doesn't mean we shouldn't try to come up with a standard way to declare/structure this sort of thing. I'll take this over to the suggestions page on assertions... --jrm03063 19:18, 22 December 2012 (EST)

I don't know if this is the same conversation or a different one, but I think a key thing we can do in developing standards for a true pando is to tag relationships where there are a significant number of people elsewhere who have asserted it to be true but we have good reason to believe either it is false or suspect. Stage 2 is then to integrate this into GEDCOM uploads so that they aren't added in by future activity. AndrewRT 19:31, 22 December 2012 (EST)

I think it's the same conversation. For starters, the assertions couldn't do more than give us a standard way to note some key things. We would keep in mind that we want to make automatic use of such data, and try to make sure that people AND programs could understand it, but it would probably be some time before we had programs making use of it. I don't think there's a sane way to objectively represent more than one structure at a time in WeRelate. When there are differing interpretations, I don't see that we can do much better than choosing the best of the bunch (presuming one is considered to be the most likely), or choosing nothing. My practice would be to discuss both the prevailing and minority opinions in "Disputed Lineages" - and to carry that "Disputed Lineages" content to the different pages implied by the various interpretations. --jrm03063 00:20, 23 December 2012 (EST)

From a more theoretical point of view - I suppose you could create a genealogy environment where any given person or family page could have 1 or more interpretations. Connections to other person or family pages would have to name both the page and the interpretation at each connection. It might be able to be done - but I wonder how usable it would be. --jrm03063 00:27, 23 December 2012 (EST)

Thinking about this a little more - the above approach might work in the most common cases - but it would probably be impractical for someone like Henry I, where there are different interpretations for a number of potential children. Assuming four children who may (or not) be his - a full page level interpretation would mean 16 interpretations. Five children - 32, etc. Would have to think about whether there's a different way to structure different interpretations, such that you wouldn't get a combinatorial explosion. --jrm03063 00:40, 23 December 2012 (EST)

After a while I figured out you had put up a formal "Suggestion" (page here). This surprised me a bit since it seems like it needs some discussion before a suggestion for software implementation could be formalized. Also, I assume we want a design that editors can start using without waiting the probable very long time before the WeRelate implementors can do anything about it. Do you think the mechanism's needs and variations should be discussed and decided upon there, or here (new topic?), or on some other working/discussion page?

I'm so sorry if my "suggestion" implied that this was in any way ready for decisions to be made. Very far from it I should think! I thought that this might be getting a bit large for to be hosted on the watercooler - and that I wanted to expand it and formalize it enough to show a direction I thought this might go. I'll mark it to indicate that it's still the subject of very active revision and discussion. When the three or four of us who have shown interest start to approach consensus, then perhaps we offer it for consideration as a standard practice/convention. --jrm03063 21:13, 23 December 2012 (EST)

Anyway, plunging ahead: The idea of using an "other" event in "Facts and Events" seems a bit stretched, but investigating it I found that it at least would seem viable. If one adds an "other" event and places the template invocation in the "description" field, then the page displays it reasonably well. For an example of what it would look like for an assertion where we are trying loudly to make uploaders/mergers/browsers aware of the assertion, see this sample page. (Obviously we wouldn't use it in a simple end-of-line situation like the sample; it's just to show how an "other event" would display. The normal event-related date and place fields would not seem to have any use.

For GEDCOM exports, the "other event" generates a line like "1 EVEN {{Parents Unknown|parameters}}" which at least makes moderate sense if we name the templates well. What various programs would do when importing such a GEDCOM event is hard to say, but at worst it probably just gets thrown away.

That's good. I suppose it's also possible that the GEDCOM export could be made smart enough to recognize and expand/transform the templates on export. --jrm03063 21:13, 23 December 2012 (EST)

The use of an event does position it well on the WeRelate page it seems to me, as for at least some of these assertions we want the display high up and visible. I guess the only real alternative to using an event field is to place the template invocation in the general "content" text box, where it might tend to get lost. --Robert.shaw 17:41, 23 December 2012 (EST)

Thanks for your careful consideration/review. Please, feel free to modify/revise/expand the "suggestion" as you see fit. --jrm03063 21:13, 23 December 2012 (EST)

Well, it looks great on the displayed page, but on a merge screen(and probably on a GEDCOM upload - been so long since I've done one I can't say for sure), all you see is the text typed in, i.e., the name of the template. Further, even at face value, my response as a user would be: "You think the parents are unknown? Not me! I know who they are! After all, I found an Ancestry Family Tree that says so!" So it should something like "Please read all notes on this page before changing.", and it probably needs to be supported by the software before it is going to matter.

In your example, the template's invocation {{Parents Unknown|not|Arthur Miller}}, has arguments. But the template itself doesn't seem to take arguments? --Jrich 22:40, 23 December 2012 (EST)

Yeah, the parameters "not|Arthur Miller" are bogus and the template as it was drafted doesn't use any; I just put them there to cover that case for viewing & export and didn't bother with display. You're right that this (or any, I guess) template won't show up well for imports or merges wihtout software support. Just seems to be a fact of life.

The "parents are unknown? I know who they are!" issue is quite real. Because of that, I'm now leaning towards explicit naming of the unproven candidate(s) via parameter. The wording would have to be different. It may be much like "Debunked Parents" in structure, but needs wording more about unsupported, not proven wrong. --Robert.shaw 23:15, 23 December 2012 (EST)

I'll offer a couple things. I don't think the templates need to expand into a box - a standard text item ought to be enough. It might also be helpful if the template expansion included a link to a page describing in greater detail what the assertion templates are meant to do and what any given template implies. Finally, as with other facts - we would like to positively support them with sources and/or a note. To be sure, until there's software support, people can do what they will, but GEDCOM import time is just one moment in the life of the data. I still anticipate consistency checking software that wanders around the database looking for combinations of facts that are mutually exclusive (parents born after children, etc.). This sort of item just becomes another fact combination detected by that process - "parent unknown" with a connected parent page would be flagged as an inconsistency. --jrm03063 10:31, 24 December 2012 (EST)

GEDCOM import is just one moment in the life, but there are others, and all the moments where a page is being changed, be it merging, editing, etc., all you see is the template name, not the template message. Adding a template is really just a negative measure, in my opinion, to stop people re-adding stuff that has been removed. However, I still feel the need is to deal with possibilities, and not just is or isn't, all or nothing. A more positive approach may be to give each fact (including parents) a status of accepted, possible and rejected, for example. Then we don't have to throw away possible data just because it's not provable. It's the same idea that suggests there can be birth dates and alternate birth dates (e.g., Person:Elizabeth Cogswell (8), Person:Rhoda Aldrich (1)), even though we know a person can only be born once. Having multiple variations is a reflection of the state of our knowledge, not of what really happened. --Jrich 11:47, 24 December 2012 (EST)

I had an exchange above w/AndrewRT on a theoretical approach to handling multiple genealogical interpretations. I don't think it can be done in a way that is easy enough for humans to understand, general enough to handle all the situations, and structured enough to make it useful for software analyzing the database. I do think there are a handful of a useful special cases that we could support though. Certainly rejected corresponds to debunked and accepted corresponds to the actual connection structure. We could have another set of templates corresponding to the "Debunked" list, that indicate potential or candidate relationship connections. I'll scratch something in for folks to look at. --jrm03063 12:40, 24 December 2012 (EST)

Use "Speculative" rather than "Inconclusive Research" assertions? [28 December 2012]

I'd suggest using specific-person/family parameterized templates (like the "Speculative Quality" ones) instead of having the nonspecific "Inconclusive Research" templates. The problem with the latter is that someone seeing an "UnknownParents" entry can just very easily think "Oh, they didn't know what I do. I can really help out by adding these parents!". In a way, it can encourage just what we want to discourage. Being explicit about the speculative parents helps avoid this. --Robert.shaw 15:58, 26 December 2012 (EST)

Of course the speculative value templates are much to be preferred, but the situations are different. Indeed, there are three to consider:

• A - one or more speculative values for a fact
• B - a fact does not even have a speculative value to consider
• C - a fact has a generally accepted value, but discussion continues on speculative alternatives

The speculative templates were meant to target situation "A". The unknown templates were meant to target situation "B". Situation "C" could be inferred by having speculative values AND ordinary WeRelate connection facts both being present. Perhaps there's a different word than "unknown"? --jrm03063 18:10, 26 December 2012 (EST)

Perhaps, instead of unknown, "NoneSupported" or "NothingSupportable" ??? --jrm03063 18:17, 26 December 2012 (EST)

Case B seems to be the normal situation for any "end-of-line" person - there are no known parents nor speculative candidates. I wouldn't think we'd want to label such cases with templates; it's very normal, really the default, and there are a very large number of such people.

I agree this would, strictly speaking, apply to normal end of line cases. I don't see using it for that however. Rather, I see this as being used to curtail a line where the field has been victimized by prior errors or fraud. --jrm03063 17:33, 27 December 2012 (EST)

Upon further reflection, I've come to see your point, and agree. I think there's a better way to do the kinds of things I had in mind anyway. So I'm going to refine the suggestion to indicate that one or more "speculative" assertions of a fact are meant to PRECLUDE an actual assertion of the corresponding fact. I also think that, if there is a generally accepted version of a fact, but there are ALTernatives that continue to be discussed, we should use a different template (more consistent with the notion of an alternate DOB or DOD fact, that we would prefix with "Alternate").

I'm also going to add a later section to the suggestion, enumerating possible assertions that we are or have considered, but are planning to leave out to begin with. It lets us formally take note of ideas considered and rejected/deferred. It's also a good test of the assertions we choose - since we want to should be able to add new assertions without changing the meaning of the existing set. --jrm03063 09:49, 28 December 2012 (EST)

The idea of having templates like "AlternateParents" (analogous to altBirth, etc) sounds like it might usefully handle some situations. This would be a situation where the box/color enhancement choice would likely be different than for e.g. "Refuted", while the latter needs high visibility, the "Alt" templates could display simple plain text. --Robert.shaw 18:25, 28 December 2012 (EST)

Perhaps. We have to be careful, and consider what combinations of multiple assertions might look like on any given page. --jrm03063 19:03, 28 December 2012 (EST)

Case C - I'm not sure what the situation is here. Say Alice has generally accepted parents Jack & Jill, but some people speculate that her parents are really Ken & Kathy. Is the intent to say that the WeRelate consensus is that Jack & Jill are in fact Alice's parents, but that some genealogists reasonably hold that may be wrong and that Ken & Kathy may be right? Or is it more that Jack & Jill are traditional, but recent evidence suggests Ken & Kathy may be, but that's not established? Or is it more like both are not all that well supported, but Jack & Jill has been most often accepted to date? Or, maybe slightly different, that evidence is not conclusive, but on balance Jack & Jill are slightly favored? --Robert.shaw 16:29, 27 December 2012 (EST)

I wanted our discussion to try to get a handle on something that was very complete - and then perhaps to scale back what we ultimately provide. I agree that this scenario is relatively less common than the others and probably is something that we need not support. Situations do exist however - where there is a generally accepted value but speculation persists on alternatives. There are situations - well known in studies of peerage genealogy - where there the paternity of some children remains in doubt. In those situations there is both a generally accepted and speculative value. --jrm03063 17:33, 27 December 2012 (EST)

It seems like these situations can make use of Alternate or Speculative templates for the non-generally-accepted connections. --Robert.shaw 18:25, 28 December 2012 (EST)

Well yes, with the "Alt" forms being understood as alternatives to the generally accepted fact. "Speculative" forms indicating that there is no generally accepted fact. Note that I put the "Alt" forms in the suggestion as not something that we roll out immediately, but that we consider after living with and reviewing a smaller initial set of templates. --jrm03063 18:42, 28 December 2012 (EST)

Expand to box, plain text, or something in between? [27 December 2012]

In a Watercooler comment, jrm03063 said "I don't think the templates need to expand into a box - a standard text item ought to be enough." Although seemingly a bit of a detail, it actually has some impact. I'm not at all sure the answer would be the same for all the templates proposed.

The reason I used a box in the original prototype was because I wanted it to be very visible to a human glancing at the page. This was so that there would be a greater chance that the presence of the template might stop someone from adding a connection that was not well supported (or have them reverse their edit afterwards). Preventing such connections is particularly important for the years before the software is enhanced to detect the template and prevent the connection.

I believe that just simple text in the fact section, like "Debunked parents: Jack Miller and Jill (2)" is most of the time going to be overlooked, and hence the template will be substantially less useful.

It might be possible to use text with some "enhancements". Using bold alone I don't think is enough. Perhaps using color background for (parts of) the text would be visually alerting enough that a box could be dispensed with.--Robert.shaw 17:10, 27 December 2012 (EST)

I see your point, and agree, there's a balance to be struck here. I'm a little concerned about what this might look like, if you were using boxes, and you had a page with two or three assertions. Perhaps there is some way to consolidate multiple assertions in a single "fact", but I think that wouldn't encourage source/note support. I don't have a good answer - I just think we need to experiment and be careful on this. --jrm03063 17:46, 27 December 2012 (EST)

Debunk not a great term... [28 December 2012]

I think that a more appropriate term like "Refuted" or the somewhat stronger "Disproven" would be a better term than "Debunked". I would actually suggest that we include both "Refuted" where one or more cited source or sources claim to refute the purported "fact" and also "Disproven" where one or more cited source or sources conclusively demonstrate that the purported "fact" cannot be true. It is important for the credibility of WeRelate that assertions that a purported "fact" is incorrect be supported by appropriate references. Otherwise who is given the authority to simply declare another person's contribution "Debunked" without offering support for this claim? How is a template that does not actually require supporting References or Notes that much better than the current situation - is it really meant to be merely a warning? We need to have some way to say WHY the purported "fact" is "Refuted" or "Disproven" - otherwise these new "fact" templates are themselves subject to error and abuse. Please note that I am VERY annoyed by all the obviously wrong stuff on WeRelate. I simply want an improvement that is demonstrably better than the junk facts it is trying to flag as erroneous. --Jhamstra 21:18, 27 December 2012 (EST)

Thanks for weighing in!

• The templates represent facts - like any other. So they really should have support. Someone coming along later who has access to additional or different sources can modify or eliminate them as appropriate.

• I agree that "refuted" is relatively less passionate/judgmental than "debunked", and so seems a better term.

• I don't think we should use any form of the term "proven" because it doesn't help us. All we ever have to care about is that the next revision of a page (or fact) builds on everything before it, and is somehow, usually, incrementally better. Whether that state reaches a threshold for "proof" isn't strictly important (however much it may be desirable).

--jrm03063 22:42, 27 December 2012 (EST)

I agree, Jhamstra, that any use of one of these fact assertion templates needs to have supporting references or notes, and we should have clear instructions to that effect. I don't think there is any effective way for the template mechanism alone to enforce that. Editors will need to manually remove non-complying usages (informing the insertor on his talk page).

And use of "Refuted" is definitely an improvement. --Robert.shaw 17:55, 28 December 2012 (EST)

Prototype assertion template [29 December 2012]

To get a feel for how the proposed templates might work, I've cooked up an experimental version of one at Template:Prototype Refuted parents and made one use of it at Person:Betsey Hildreth (1). What problems do you see with this version and how might those problems be solved? --Robert.shaw 18:14, 29 December 2012 (EST)

I like it. Might be time to think about what the other classes of assertions look like. --jrm03063 21:11, 29 December 2012 (EST)

Refuted spouses [31 December 2012]

I am wondering about Refuted Husband / Refuted Wife on the Family page? Is the intent here to indicate that one parent and one or more children are believed to have existed but that one parent is Refuted (or both parents in the case of known siblings)? A peripheral question is the use of the term "Husband" or "Wife" when there have been children but there was never a marriage? (This has happened many times throughout history.) Perhaps the term "Partner" or "Consort" might be more appropriate in these cases?

If there were no children and no evidence of any marriage then I think it would be better the place the Refuted Husband/Wife/Consort/Partner assertion on the Person page. The should NOT be a Family page in these cases because there was not a Family.

If there were children and one or both of the Parents are Refuted, then I think that perhaps a Refuted Mother/Father designation would be appropriate on the Family page.

--Jhamstra 15:00, 30 December 2012 (EST)

I see what you mean and agree. We don't want to create family or person pages, that wouldn't otherwise exist, just so that assertions have targets. Also, in cases where a marriage/partnership was thought to exist, but in fact did not, we still want to have symmetric and useful links between the (un)related person pages (assuming that the people are both real and only the marriage/relationship was a fiction). So indeed, Refuted[Husband, Wife, Partner, Consort] can make sense on a PERSON page.

I also like the idea of a single gender neutral assertion over two gender-specific forms. On the down side however, that wouldn't be consistent with existing terminology (even though husband/wife are already being slightly abused for children of parents not formally married). Then again, it's a new millennium and all - and our structure records and represents whatever formalities of marriage the partners did, or did not, elect to observe. If others are satisfied letting go of the gender-specific terminology, I certainly won't object. --jrm03063 16:29, 30 December 2012 (EST)

The above comments made me realize I don't understand how many of the potential assertion templates should be used. The possibilities seem fairly confusing. I haven't figured this stuff out yet, but here are some thoughts.

I'm concerned here with what templates are used where and when, and not their names. The names (gender-neutral or not, etc) need to be figured out, but first we need to understand usage.

It seems pretty clear to me, and suppose most agree, that when a family exists and a person who potentially is a child in it exists, the template usage is straightforward: a Refuted Parents (or Speculative Parents) can be placed on the Person: record and a corresponding Xxx Child placed in the family.

Some other cases we may want to cover with assertions might not work like that, between a Person: and a Family:. Maybe the strongest case would be a potential spousal relationship. Without children in the picture, it might make more sense to specify Person: to Person: assertions, e.g. the male Person: having a Refute Wife pointing to the female, and she having a Refute Husband pointing back.

In this case, I don't think it's useful to involve Family objects; they just seem to get in the way. I think a family need only be considered where there is a child and at least one other member (father, mother, child).

That right - that was the case made and I agreed. We don't want to create person or family pages that shouldn't exist in light of the accepted state of things. So we'll also allow use of templates like "refuted partner" (or whatever) on PERSON pages. --jrm03063 09:09, 31 December 2012 (EST)

Now, what about a case where say there is a speculative father for a person but no other potential persons (no speculated mother or siblings)? Should we have a Person: to Person: pair of assertions, or should there be a Family: page involved? If the latter, then should it be the child-to-family or family-to-father connection that should have an assertion pair? Both? The P-to-P pair seems less byzantine and desirable, and the Family: artificial.

Is it the same answer if a speculative father has a couple of marriages, perhaps with other children, either of which could be to the child's mother?

What if a speculative father has one marriage known but no others? What if he has one marriage, and is known to have not had any other marriages producing offspring? In what cases do we want to have P-to-F and/or F-to-P assertion pairs instead of a P-to-P pair of assertions?

We want this to be a simple rule - so we don't tie ourselves in knots. I come back to the notion that we want to go "P-to-P" if creation of the intervening family page is not justified by other generally accepted facts.

Was I wrong when I said with an existing family we use a child-to-family assertion pair? Would a P-to-P, child-to-father assertion pair be better? (But not if specific to that couple, but not to other wives of the father? In that case, should it have been a P-to-P, child-to-mother assertion pair?)

In general, I think no. So long as the family page is justified by other generally accepted facts, that support full siblings, or at least one of the two parents.

Well, I'm confused. Need to ponder more. --Robert.shaw 22:28, 30 December 2012 (EST)

Counts of things - save for later? [30 December 2012]

As much as I think the counts of things assertions are important, they don't seem as immediately useful as the others (being mostly of value for software that's doing consistency checking - which won't exist for a while). They also depart from the mostly standard form of the other "familial connection" assertions. Since the project page/suggestion is explicit about attempting to roll out in limited form, while describing possibilities that could be added later, how about we move the "counts of things" assertions to being a future direction? --jrm03063 16:50, 30 December 2012 (EST)

I'd favor moving the count assertions into the Futures section. --Robert.shaw 18:31, 30 December 2012 (EST)

Shall we take this to a more concrete experimental phase? [1 January 2013]

I'm not (yet) for rolling this out without wider consent, but I think it's perfectly reasonable to pick a handful of real person and family pages where we'll experiment with the templates. We'll track them on the project page, and indicate what each one serves to demonstrate. After all, we would need live examples for example purposes when it's submitted to a wider audience anyway. Choosing a few pages for use on an experimental basis doesn't seem apt to be offensive. I've taken the existing single example page and added a corresponding Refuted Child template. I've also noted the "pair" as an example assertion in the project document.

BTW - I think that the templates should include a link back to the suggestion page (for now). Assuming adoption by the community, that hook would become a link to a help page. A simple "?" might be enough. --jrm03063 11:34, 31 December 2012 (EST)

Yes, it's valuable to expand the extent of the prototype slowly to see what issues might pop up. Here are a couple:

1. A link to an explanation/help page is good. We can use the "?" like you set up, or could link the "defining words" like "Refuted parents:". The latter is less visible, which might be considered a drawback. The "?" might have a slight tendency to be confused with the "?" that often appears by the event name and links to a "citation needed" page, but that isn't much of a deal, so let's continue with "?" for the present.
2. The new Template:Prototype Refuted child page raises a structuring issue. It says it can be used on either a Person or Family page, and says the "Refuted parents" template should be added to the target page. The problem is, the "Refuted parents" template as it stands handles only pointing to a Family page, which is not the appropriate thing if the "Refuted child" is placed on a Person page instead of a Family page.

   There are probably multiple ways to solve this problem. One would be to have separate templates with distinct names. In this instance you could have "Refuted parents" versus "Refuted father"/"Refuted mother", but for other template pairs the alternate names might not be so pretty (and of course we want a consistent approach). Maybe we need to figure out exactly what names would be needed for all the cases. (The displayed text could be different too e.g. "Refuted father?:" versus present "parents?:")

   Another way is have the one "Refuted parents" template take an additional parameter which can flag which type of link is needed, e.g. P or F. Templates can have conditional code so this could be made to work. The flag could distinguish father/mother too if we wanted the displayed text to vary also.

   A third way is to require the invocation to include the "Family:" or "Person:" prefix in the parameter value. I don't like this because it is bigger burden on the invocation editor and worse on every reader of the page, who really shouldn't have to read these pieces of technical verbiage.

   A fourth way might be to parse the parameter value and detect the "and" that occurs in any Family page name, and then generate the appropriate stuff. This may well be possible, but that is beyond my present knowledge of template internals.

--Robert.shaw 17:38, 31 December 2012 (EST)

Lets take the simple approach - RefutedParents implies a FAMILY page as a target. RefutedParent or RefutedMother/RefutedFather implies a PERSON pages as a target. I'll look at the general forms again... --jrm03063 20:59, 31 December 2012 (EST)

Yes, that looks like the right thing to do. --Robert.shaw 15:21, 1 January 2013 (EST)

I have a definite candidate for refuted wife. I have been straightening out the mess but still need to write it up. With my son here; he takes over my laptop; it will probably be Tuesday before I am able to complete the article. But anyway this would be an excellent page for the experimentation.--Beth 17:53, 31 December 2012 (EST)

Sounds good. Are you going to want to try the RefutedWife and RefutedHusband templates? --Robert.shaw 15:21, 1 January 2013 (EST)

Can everyone skim the updated general form as written now? I think we're really getting somewhere here. --jrm03063 21:47, 31 December 2012 (EST)

I think it's coming into shape. I just revised the first part of the Family Connection Assertion Templates section to use a table for presentation. I think it makes it easier to fathom what's going on. The process of creating it made things a little clearer to me, for instance by showing me there were two groupings of template types: parent-child and spouse-family. --Robert.shaw 15:12, 1 January 2013 (EST)

It did seem to me that the cross product of possibilities contained some subtle cases. It made my head hurt to think about it - I hoped it would become more clear if we pursued this with some care. --jrm03063 15:45, 1 January 2013 (EST)

Refuted alone? Or Refuted and Nonexistent? Or clever template syntax? [1 January 2013]

With the addition of the second example, I see the unfortunate results trying to support a parameter that may, or not, represent a valid remote page. Perhaps then, instead of just "Refuted", we add "Nonexistent", to indicate a situation where a family connection isn't just refuted. It represents a person or family that (at least in this context) never existed. Alternatively, perhaps someone clever can figure out how to recognize the difference between the strings, "John Doe" and "John Doe (86)", such that the latter form is turned into an active link and the former is either simple text (or perhaps) bold fact text. --jrm03063 15:42, 1 January 2013 (EST)

I'm not sure I detect any particularly bad results when using a name parameter which is not a page name. It's true that it causes the name to have an underlying link, but clicking that link doesn't have too terrible a result: it goes to the normal WeRelate absent-page display, which says "(There is no information on this family. To create the page,...". That seems fairly reasonable to me. If the name represents a real person or family, someone could actually enter a new page for the person or family at that point. What aspects do you think are unfortunate? (I'm not sure how one can be sure that a person of a particular name never existed.) --Robert.shaw 18:00, 1 January 2013 (EST)

I sniffed around on template syntax, and while I didn't try any experiments, it looked like there might be way(s) to branch on "*(*)". I think we can leave things as they are, and presume that we'll be able to do something wiki-clever eventually. --jrm03063 18:15, 1 January 2013 (EST)

Would "refuted" be an appropriate way to indicate often confused with? [5 January 2013]

Saw the changes to John Webster, and the lengthy narrative on confusion of two different John Websters. As we've discussed it so far, we're generally talking about refutation of a formerly accepted/published fact/person assignment. It seems that lesser sins would benefit as well. I've often been in the situation of seeing that we have a parental assignment that came from one or more GEDCOM uploads - it's incorrect - but I have no idea what motivated the original choice. I don't think I should have to - it's enough to know that someone made the mistake in practice.

Perhaps we could look for talk pages that contain the "do not merge" directive, and we would probably get a long list of examples of pages where there was potential for confusion.

We can also search on my "Disputed Lineages" section, which I've added in lots of places, where someone created or uploaded something that wasn't supported.

I'm also going to offer a small "oftenConfusedWith" template to the list of potential adds.

--jrm03063 11:51, 2 January 2013 (EST)

The John Webster, baker of Salem and caught brewing there, is certainly a good deal more likely to be the brewer of Portsmouth than the John of Ipswich. I don't think "refuted" quite fits since it's not a relationship to another person that is in question but rather attribution of the Salem records to a person. One clearly should not attribute the Salem records to the Ipswich man since there is a better candidate, but whether you can attribute them to the Portsmouth man is not completely solid. You could say it's a question of identity I suppose. I guess we don't have any assertions about "identity of self" other than the proposed OftenConfusedWith. That one may do, although it isn't necessarily "often". Could be "Sometimes" or "NotToBeConfusedWith" or some other wording. Not sure if more than one assertion in this realm is needed. --Robert.shaw 17:27, 3 January 2013 (EST)

Ok, I'll try this with "NotToBeConfused" instead of "OftenConfused". I also feel like this is useful enough and simple enough to be part of our initial roll out, so I've moved it up in the spec. Beyond that, I've left the spec alone, but I will try to see if we can get by with a single "NotToBeConfusedWith" template, that uses the namespace of the source page as a prefix on the parameter for the target. --jrm03063 18:34, 3 January 2013 (EST)

Doing this with a single template turned out to be trivial. I've gone forward with that accordingly. --jrm03063 18:50, 3 January 2013 (EST)

Very nice that you got it to work for both namespaces. I think this template will be useful. --Robert.shaw 17:10, 4 January 2013 (EST)

As to finding some (not all!) candidates for assertion template usage, it doesn't seem hard. A WeRelate search using keywords or a Google site search easily turns up pages. I've used "Disputed Lineages", <parents refuted>, <parents disproved>, and other things to turn up pages, e.g. the Samuel Allen one. I have some saved for later. I just turned up Family:Benjamin Woodworth and Hannah Unknown (1) which might be a refuted wife candidate. Earlier I found Family:William Varney and Bridget Deverell (2) which has 2 wives in the family structure plus another mentioned in the page body; it needs cleaning but not sure how or which refuted- or spec- assertions would be right. Anyway, seems like there are lots of candidate pages around, although for the no-page case that Sam Allen filled I did have to examine a medium number to find the kind of page I needed. --Robert.shaw 17:27, 3 January 2013 (EST)

I've created a boat-load of "Disputed Lineages" sections over the years. It was my initial attempt at creating a standard approach to problems of the sort we're talking about here. I created it only because no one offered a convention and I thought we should do something more or less standard. While I think most people found that to be a useful approach, I never asked that we make it a community convention or tried to hold a vote. As a result, some folks with narrow views have ripped them out here and there. When we think we're ready with this set of assertions, we should be sure to get community buy-in that prevents that unfortunate sort of chaos. It would be nice to get rid of those sections in favor of objectively useful facts. --jrm03063 18:34, 3 January 2013 (EST)

I'm surprised any editors would rip out a Disputed Lineages section; reword it maybe to reflect their view, but it's important to retain knowledge of what genealogical directions might be around to trip one up. I don't see the assertion templates replacing Disputed Lineages sections in many cases other than when the Disputed Lineages just gives some basic facts. If there's discussion of the lineage, such a section seems appropriate in addition to an assertion template, as cramming everything into a note attached to the assertion would often be too limited. --Robert.shaw 17:10, 4 January 2013 (EST)

Some editors hold my contributions in special "respect". --jrm03063 18:00, 5 January 2013 (EST)

Template Naming Conventions - as is or prefix "Assert"? [2 January 2013]

I'm wondering whether the template names, that we're presently contemplating, are obvious enough as assertions? Or should we have a standard "Assert" prefix - so that instead of "RefutedFather" - we would have "AssertRefutedFather". I realize it's more to type, but there might be value in making it more obvious that a template is part of the "Assert" set. --jrm03063 12:12, 2 January 2013 (EST)

I favor the simpler form without Assert. Besides the extra typing, it's extra reading and fills up the Description field and the Gedcom event type. I don't think it adds much value. Pretty much all statements on the site are assertions. If someone is familiar with the existence of the set of Assertion templates, they can come to a central page (like the Suggestions subpage at present) to find out what's available. If they are looking at a page invoking one, the "?" link will take them to something mentioning the Assertion set. If they are looking at a particular template page, the documentation on the page will have links to an appropriate page for the set. --Robert.shaw 17:07, 2 January 2013 (EST)

I don't have a strong opinion - but thought the question should be put. --jrm03063 17:28, 2 January 2013 (EST)

Should be reviewed in context of semantic wikis [2 January 2013]

I suppose it should have been clear before, but what we're really doing is adding semantics beyond those already present in WeRelate. I'm a little concerned that we're creating/adding ad-hoc semantics to WeRelate. While that isn't fundamentally a bad thing, we should consider how this information would be implemented in an actual semantic wiki. Certainly, we don't want to do things in ways that are gratuitously different or unfamiliar to someone who knows about semantic wikis. --jrm03063 13:10, 2 January 2013 (EST)

I'm only slightly cognizant of semantic wikis, but I wouldn't worry about it for this. First off, this is a site for people to read and to access via genealogical standard mechanism (i.e. GEDCOM at present). Second, I think what we're doing is compatible to a reasonable extent with semantic wiki access: it is adequate for structured access by programs. It separates off to a formally named field the identity of the assertion and the identity of the related person/family. Given the very immature state of semantic wiki mechanisms, I think that is enough. --Robert.shaw 17:17, 2 January 2013 (EST)

I agree that, if we've got something that's objectively readable by software, we can turn it into anything. I just thought we might have a user or two who actually knew something about them, and could therefore let us know if we were traveling afield... --jrm03063 17:29, 2 January 2013 (EST)

Almost ready....? [6 January 2013]

I'm thinking this is almost ready for review by a wider audience. I added the rest of the templates that look like they would be part of the initial set. I re-ordered a couple of the document sections in a way that seemed to me more sensible. I added an example of use of the speculative parents/child templates. Remaining to do:

• Add / finish up / proof the assertion template documentation files
• Add more examples to show behavior of other templates

Thoughts?

--jrm03063 19:18, 5 January 2013 (EST)

Yes, just about ready. I'm currently working on the doc text and will put in pages soon. --Robert.shaw 14:34, 6 January 2013 (EST)

Just so we're clear - we're going to propose this as a binding standard - right? We want to be sure of enough community buy-in so that this is a uniform practice. I presume that means we would need the oversight committee to review it - and provided they agree - they either issue it as a decree or offer it to the community for further discussion and a vote? --jrm03063 15:38, 6 January 2013 (EST)

I suppose that's the thing to do. I'm relatively new around here and don't know how things work. I think we definitely would like some kind of buy-in so that it does become generally used. (I've found a number of unused templates sitting around.) There's a need in this area, and this mechanism does a fair job of filling it. --Robert.shaw 16:29, 6 January 2013 (EST)

Ok, I've put JBS66 on notice (member of the oversight committee). --jrm03063 16:56, 6 January 2013 (EST)

I've put draft docs in for the rest of the Refuted templates. I've drafted docs for the Speculative template, but only installed the draft for Template:SpeculativeWife. Maybe you could review it and I can adapt my set of drafts as needed. The two introductory sentences might be of particular concern -- it says something about not having a generally accepted value. If that's really the way we want these to go, then it suggests that there may be some need for the Alt set of templates. The second sentence almost has a gaping hole where something like "; if there is an accepted wife, the AlternativeWife is appropriate." I guess I'm not fully convinced that using the Speculative template when there is already a linked accepted connection is not advisable. --Robert.shaw 16:29, 6 January 2013 (EST)

Interesting. As I think about it, it's probably not reasonable to expect people to realize that one or more speculative values (for a family connection) precludes an ordinary connection of that type. Indeed, that seems rather artificial. Perhaps, the better way to go (if we need to preclude a particular connection), would be with the specific inconclusive/unknown connection templates (in the to be added section). If we could have a little software support - it would probably be fairly straight forward for a person page to refuse to allow check-in - if it contains both a value for the parents and an "InconclusiveParents" template. --jrm03063 16:56, 6 January 2013 (EST)

"Unknown" -> "NoAccepted" Connection, added to candidate set for first release [13 January 2013]

Reworked the "unknown" template as the "No Accepted Connection" set of templates. Since I actually had use of it and thought that the "NoAccepted" string was more meaningful than "Unknown", I went ahead and created the set and added it as part of the content for the first release/go-round. --jrm03063 15:28, 11 January 2013 (EST)

Seems reasonable. Probably will have fairly limited impact until there is system support for connection blocking, but it's good to have it in place so it can be used. My guess is that at least some people will pay more attention to an instance of one of these new templates if there is also use of a Refuted or Speculative template which names the connection target they were considering adding. --Robert.shaw 00:56, 13 January 2013 (EST)

I was also thinking that, in the wider discussion that presumably will be coming, there would be room to drop this part if appropriate. I'm glad to have added it though - it gave me a little more experience trying the set of "familial connections" on a different assertion. I've noticed that a bit of overlap seems to be fundamental. For example, Eystein Ivarsson is believed to be the father of several children, but there is no accepted mother for the children. If assertion of no mother is placed on the family page, and no wife is placed on Eystein's page, the information appears redundantly on Eystein's page. --jrm03063 10:40, 13 January 2013 (EST)

Roll Out Steps [13 January 2013]

We've received guidance on how to roll this out for experimental use, and eventual offering as a community standard, which is:

"The first would be to come up with a plan for moving the text/examples to an appropriate Help page. Do you think it should be a standalone page, or included on another Help page, where do you think it should be placed? Secondly, you & your team could bring this up on the Watercooler informing users of the new features that are available for use. You could also mention that if users have questions about the new templates, they could post on the "insert title of" new Help page."

The ideal location for this information would be a help page on the entry of facts, but there isn't presently such a page. The closest thing to that seems like the Style guide, referred to in the section on Person pages as well as that for Family pages. So here's what I'll plan to do:

• Write a new help document on how to use facts, as they exist today.
• Create a second document, drawn from the assertion proposal, describing the capability and proposed standard

I think it's probably acceptable if I just go ahead and start on the document on how best to use facts, since it's a hole in our documentation anyway. We can probably start our assertion-specific document as an appropriate sub-sub-page off the suggestion somehow...

???

--jrm03063 16:00, 13 January 2013 (EST)

Adding/rework of proposal/suggestion [23 January 2013]

Suggestion/proposal document being reworked to be useful as an initial 'help' document. Content of the former Examples section distributed to the sections for the fact types to which they relate. Future directions has dropped types that are essentially synonymous with existing types, while more explicitly taking note of the potential to add special support for input and output. --jrm03063 19:07, 20 January 2013 (EST)

It seems to me it might be best to have separate Suggestions/Assertions and Help:Assertions pages. The draft Help page can be initially placed somewhere outside of the Help: namespace if that seems advisable, but I'd guess it'd be okay to put it there.

The reason for separate pages is that the audiences being addressed are different even though much of the content would probably be nearly identical. The Suggestions page needs to describe needs, justifications, overall structure and things like alternative approaches and future possible enhancements. On the other hand, a Help page needs to give what a user of a assertion needs to know to successfully use that particular assertion. The latter's audience does not want to study the overall proposal, they just want to get their job done. They may be entirely new to the concept or may just need a reminder of the syntax to use, but they are not looking to evaluate the mechanism as a proposal. I think the mechanism is solid enough at this point to copy out the operational description part into a separate help page so that the latter can be tailored to the needs of a help user. --Robert.shaw 16:30, 21 January 2013 (EST)

I agree - I havn't got there yet. But I also want to make sure I don't just re-write the same content too. --jrm03063 17:01, 21 January 2013 (EST)

Ok, I've broken the content up a bit. Help:Assertions contains a help-specific introduction, and transcludes content on the specific assertions. The specification has been changed such that the specific assertion information is also transcluded from the same place. --jrm03063 17:46, 21 January 2013 (EST)

I've revamped the Refuted Family Connection section of the help in an attempt to tailor it to help visitors. In particular, the "?" on the assertion fact display will link to it, so the person/family page reader is the primary audience and tailoring target. I'm about to fix the "?" links. Then I'll do the same for Speculative and probably NoAccepted. Discuss or revise as inclined. Once this is done I think it can be brought up on Watercooler. --Robert.shaw 15:38, 22 January 2013 (EST)

That looks pretty good! By all means, proceed with the announcement.... --jrm03063 17:01, 22 January 2013 (EST)

Okay, I'll post a WC message. --Robert.shaw 14:01, 23 January 2013 (EST)

Speculative parents [4 September 2013]

I find it useful to use the SpeculativeParents / SpeculativeMother / SpeculativeFather templates in the Description field of the Birth or Alt Birth facts. For an example see Isaac Newton, whose father is known but whose birth mother is uncertain. --Jhamstra 09:43, 4 September 2013 (EDT)

Excellent! That's just the sort of situation we had in mind! --jrm03063 10:10, 4 September 2013 (EDT)

It seems like an excellent innovation to me; I hadn't thought about using it on normal event entries, but it makes perfect sense. --Robert.shaw 16:04, 4 September 2013 (EDT)

Now that I look at it, I see that it is a little different than the way I might have used it. Since the father is known to have had families with both of the named women, I would have named the child as speculative in both of the families and indicated both of the families as speculative parents for the child. So the pairing would have been the child with the two families - rather than the child with the two different mothers.

I wonder if there's any reason to prefer one pairing over the other? --jrm03063 16:28, 4 September 2013 (EDT)

Cohabitation without marriage formalities [31 August 2016] (transplanted from WC) [3 September 2016]

I went wandering through our lists of English and Scottish royals this morning and, of course, came across numerous usages of our template {{CohabitationWithoutFormalities}} and the less common but not unknown {{Speculative child?}}. Both are printed in jaundice yellow and jump out from the page, making it difficult to concentrate on other facts that might be more of interest.

Could we tone down the colour or remove it altogether, and quietly face the fact that adultery, bigamy and illegitimacy have always happened. We are not here to judge people of past times. --Goldenoldie 10:17, 25 August 2016 (UTC)

I don't think the colour was meant to be judgemental -- it's the same colour used on all the family assertion templates, including the adoption templates and speculative spouse templates. I'll admit it is a bit garish -- I think it's meant to stand out so that it's hard to ignore when someone else wants to edit the page. Gayel --GayelKnott 14:31, 25 August 2016 (UTC)

Use of the Fact Assertion templates can be helpful, but is not mandatory. WeRelate:Suggestions/Assertions provides a good overview as to why they were created, if you'd like a refresher. I agree with Goldenoldie that they do not render well, so I don't use them very often myself. I have often wondered if anyone has found them beneficial for GEDCOM export. Can anyone comment on that? Regards, --cos1776 15:30, 25 August 2016 (UTC)

The color was used on the original assertion templates like Template:RefutedParents where it was believed to be very important to call attention to the fact. For instance, if a couple is commonly said to be the parents of a person but evidence shows that they are definitely not the parents, it is important to call attention to that fact so that readers are aware of that fact (and don't try to add the wrong "parents").

For the Cohabitation template (which probably just copied the code), I see no reason that the cohabitation fact needs to be shouted out. Unless there are objections, I'll remove the colored background in a day or two. --robert.shaw 15:35, 25 August 2016 (UTC)

It is annoying that these facts are made to stand out prominently on the page. Consider for example, Refuted Parents. When you think about how refuted parents come about, it is the mistake of people like us that do poor research. The person whose page it is (and whose page should honor, or at least, represent their subject) clearly knew who their correct parents were and played no part in having the mistake made about their parents. So it seems disrespectful to make the most eyecatching item be a statement that we made a mistake about them.

Second, if it is important to call attention to fact like these, it is probably necessary to provide something of an explanation. For example, how it is known there was no marriage? Or how the genealogical community was fooled into assigning the wrong parents and how do we now know that this identification was an error. This usually requires a note, since a simple source citation would require tracking down the source and reading it, which very well may not be something a reader can do in a timely manner. So if one thinks the fact is so important to be flagged with a special fact, it is important enough that an effort should be made to make the explanation easily accessible to the reader, i.e., by providing an analysis that explains why an apparently non-intuitive fact is true. If this is done, it then seems like the presence of the note itself then provides the notification that readers to be aware of this fact. Thus it seems like these tags serve no purpose, in my opinion. --Jrich 16:04, 25 August 2016 (UTC)

I'm pleased to see that others also feel that the colourful nature of Template:CohabitationWithoutFormalities was unnecessary. I wasn't aware of Template:RefutedParents, so did not know that the style of the former came from the latter. The two situations are so different. Template:RefutedParents deals with genealogists' errors which might be fixable; Template:CohabitationWithoutFormalities deals with facts which more than likely did occur.

I agree with JRich. The Text Area is there for explanations. Let's use it. --Goldenoldie 14:17, 26 August 2016 (UTC)

Based on the consensus discussed here I've removed the Jaundice Yellow color in the template result and modified the wording in the resulting fact line of a Family Page to reflect only the single word "Cohabitation" rather than the more lengthy "Cohabitation Without Marriage Formalities." I believe the longer term is redundant, in that cohabitation literally means two unmarried people living together without legally or formally registering their relationship (for the most part, I suppose). Hopefully that addresses the perceived judgment concern.

I agree that notices of genealogical errors or challenges to established fact events should be highlighted as something needing to be fixed, investigated further, or visually brought up as a challenge, therefore the bolded jaundice yellow color seems appropriate in those "Refuted Cases." --BobC 15:56, 26 August 2016 (UTC)

Agreed. Although the single word "Cohabitation" might be altered to "Cohabitation. No marriage found." just to inform the visiting reader. -- Goldenoldie 09:21, 27 August 2016 (UTC)

"No marriage found" is not always the same thing. A person may have multiple concurrent partners and associated children. There may be a record of them declaring one of the partnerships is not a legal marriage, and there are other possible ways of reasonably deducing that a liaison was not under a formal marriage. "No marriage found" in fact is a common state of genealogical knowledge for cases where one can generally presume that in fact there was a marriage but a record, if one exists, has not yet been found. --robert.shaw 20:06, 27 August 2016 (UTC)

I agree with Robert's statement and would expand that by saying that we shouldn't use the term "Cohabitation" solely because a marriage record has not been found or the actual marriage ceremony has not been identified. Also, adding the wording of "No marriage found" to the template wording would once again limit the scope of the much more broad meaning and use of "Cohabitation." Users should be encouraged to add such defining terms and relationship characteristics to the description field in freeform style following the template to further characterize what was known about the relationship rather than have it included in the actual template terminology.

I've created a graphic below to show the varied usage of the template term, while not changing the template itself.

You might notice my use of certain cohabitation terms. Rather than delving into the specific definitions here, I'll include these in the template page. Many of these terms are relatively new creations, so probably would apply to more contemporary relationships (which would imply involving living people). So they should be seen for use of free style wording, rather than as limiting terms.

I might also add that I don't feel it appropriate to use the template under the "Marriage" event on the Family Page, because it is not a marriage, it is a relationship event OUTSIDE marriage, therefore should be included as an "Other" event (as shown above). Marriage events should be reserved for relationships that were known or presumed to be legally or religiously formalized. (That's my common-sense analysis, although I'm not certain how that would reflect in a GEDCOM export.) --BobC 14:31, 30 August 2016 (UTC)

This conversation is now begging another question: Is there an easy was to find a list of this type of template? Or, putting it another way, have our templates been properly categorized? In the light of the discussion of categories of about a month ago, I can see some people saying "not that again" but, being an analytical type of person, what I just found in a browse of templates does not look good. Category:Communications templates has everything in it--kitchen sink of unwashed dishes included! -- Goldenoldie 09:21, 27 August 2016 (UTC)

I don't know about other people, but I usually use the Template search and enter my best guess at the template name in the key word field. Seems to work reasonably well for me. There is also a category called Assertion templates. I use the speculative templates a fair bit, and have also used the refuted templates on occasion where there seems to be an internet-wide belief in a given relationship that is unsupported by documentation and/or that has been disproven. Gayel --GayelKnott 14:55, 27 August 2016 (UTC)

You can find templates "of this type" at Category:Assertion templates. (An overview is at WeRelate:Suggestions/Assertions and the help text associated with the templates is at Help:Assertions.)

By the way, there is a pretty diagram of how templates are categorized at Category:Templates, but it probably hasn't been updated since 2011. Personally, I usually find a template by a Google search of WR for "template" and some possible keyword(s). --robert.shaw 20:06, 27 August 2016 (UTC)

The expansion of the Cohabitation to, what is it? 10 varieties? seems to show someone completely enamored with the technology who has lost sight of the original goals. In the case of the "cohabitation" and refuted parents, of course, it is to alert people to potential genealogical errors if they, like many, practice genealogy by assumption or reliance on single secondary sources. As in assuming one spouse is dead because the other spouse remarries, or making similar assumptions when determining which parents a child goes to, etc. Now it seems like the templates are becoming judgemental, instead of merely being an objective warning that normal conventions don't apply for the current case. Plus the number of times it can be proven *by actual evidence* which of the many cases is appropriate is getting smaller and smaller as distinctions get finer and finer. A simple "Not married" in the description field accomplishes much the same thing. If you're interested, then read the sources and narrative to find out more.

A related discussion on another page listing other similar templates for combat roles and other historical events seem me to tread all over the purpose of categories, and seem to be an unnecessary cluttering up of pages, much like various banners popular in some circles. These appear to be important to one person but perhaps not to others. A true descendant may well rather write about some of these things in some detail in the narrative, and a category is like to provide all the necessary grouping functionality needed. Then on top of that is the realization that not a single page that comes in by GEDCOM will have these templates, nor is there a mechanism to automatically insert them, plus the fact that any number past say 7 (e.g. telephone number length) are likely to be too many for uninterested people to remember easily, and all the templates being so gleefully discussed will end up being implemented by one person only, because they are his creation, and will end up being useless because they are not used by a critical mass. Not to mention that "facts" needs sources and proof so suggest that even more thorough documentation may be required.

A question was asked on yet another page related to this topic about data management. Well, most data management starts with a central data dictionary that ensures data use is consistent across an organization and meshes with the corporate purposes, i.e, reflects how the whole organization uses the data. Then good data management will have active enforcement so that these definitions can be counted on. How weighty of a source has to propose an incorrect set of parents to justify adding a Refuted Parents template? Surely some random website wrongly identifying the parents would not justify a RefutedParents template? Any book in print? Any error printed in at least 2,3, or some number of books? If the purpose is to warn of errors, how do we warn of errors that give parents not in WeRelate so that the RefutedParents can't link to anything? What about parents that never existed because they were erroneous themselves? Do we need to provide the sources and explanations on both RefutedParents and RefutedChild, or can we assume RefutedParents will link to a Family page that provides the sources? Will a bot be developed to find unmatched Refutes? How much evidence is necessary before SpeculativeParents become RefutedParents? Will the presence of a RefutedParents block some GEDCOM from reattaching that child to the wrong parents, much the way the nomerge template is able to prevent merges? --Jrich 18:14, 31 August 2016 (UTC)

The discussion of cohabitation without marriage formalities has shown me that use of the term "cohabitation" was a mistake. My intent was to characterize any degree of marital life - from the minimum required to produce children, up to and including a relationship that modern eyes would recognize as (at least) a common law marriage. I didn't intend it to imply anything about the amount of cohabitation - only that a legal (in contemporary terms) marriage ceremony is not believed to have ever occurred. Beyond the standard reason of trying to work with the fact/source/note support of GEDCOM, I wanted this template for a couple reasons -

• Provide a standard appearance for such relationships - that eliminated use of judgemental/gender-biased terminology.
• Provide an objective way to mark relationships that would otherwise be understood as bigamy. Error detection software could be created to walk the WR database - which would be expected to warn about cases of bigamous marriage. As assertion of this sort could prevent appearance of a lot of needless warnings in the medieval/noble spaces.

Perhaps, it should simply be named "NoMarriageFormalities" or even just "Unmarried"? Expanding to "No Marriage Formalities" or "Unmarried" as may be preferred. I agree that the old yellow text was wretched - but I do feel like something a little different than ordinary text is called for. Perhaps italics or bold? --jrm03063 15:17, 3 September 2016 (UTC)