Source talk:Find A Grave

Seeking Input... [8 November 2011]

I've organized this page a bit, and offered a couple of examples that I would think would be the preferred way to cite Find A Grave, when used on a person page or when used on a cemetery place page. These depart a bit from the common forms I've found, where a naked URL appears (or even nothing). --Jrm03063 11:18, 3 February 2011 (EST)

I have a small concern that the proposed way of showing a link on a cemetery page, such as it is currently on Western Cemetery, could actually end up obscuring what we're trying to highlight (which is the link to that cemetery's page on FindAGrave). I'm not certain that most people would realize that there are two separate links there. But I could be persuaded to have both, especially if the link to the actual FindAGrave page comes first.

I think I moved the FindAGrave link first - I would like it to appear more like a typical person/family page source citation.

On the Person page, such as Stephen Longfellow, what do we gain by having an exception to how source citations are normally entered? Other than it being "prettier," I don't think we gain anything by having people enter the URL in the "Record Name" field (and having to format it in a specific way), rather than just having them input the URL in the "Text/Transcription Location" field. In addition, putting the URL in the "Record Name" field changes the look of the citation. Compare the FindAGrave citation for Stephen Longfellow with the one for Frederick Strickrott. Frederick's has the URL for his FaG memorial page in the Text Location field and is more consistent with how other citations look on WeRelate. Without a clear and substantial benefit, I am very hesitant to make citing sources any harder/more complicated than it absolutely needs to be. -- Amy (Ajcrow) 15:17, 3 February 2011 (EST)

It doesn't seem exceptional to me. It's not just prettier - it provides the logical information on the link so that if something happens to the URL there's still hope of finding the intended content. I also see a URL as more like a page or record specifier - not the content itself. I see the body of a citation as the place where a section of content is quoted. I've done tens of thousands of Wikipedia, thepeerage, and FMG citations in this manner.

--Jrm03063 21:41, 3 February 2011 (EST)

In that the procedure is different than how it is normally done, it is exceptional. I disagree that it helps if the URL breaks. Just having the person's name display instead of the URL doesn't resolve anything. If anything, it obscures what the intended page was, as you've lost even the domain name. Yes, you can backtrack through the link to the Source page or go to the Edit page to see what the link was, etc. I just don't see where we are gaining anything substantial by having people cite Find A Grave differently than they typically cite any other specific page on a website (and having to format their entry, at that). Remember, not all WeRelate users have done tens of thousands of such pages. Many (I wouldn't be surprised if it is most) of our users are newcomers to a wiki environment. Having exceptions to rules only complicates things for them, making them less likely to become active participants. -- Amy (Ajcrow) 22:18, 3 February 2011 (EST)

Lingering over the link should expose the full URL somewhere on your browser. You don't have to edit it to get there. Also, in the context of a source, the source page link itself should provide a nice way to get to the primary/common entry point for the source information.

I agree with Jrm. I don't think it's exceptional from the preferred method whether there is a singular entry being referenced - that's what Record Name is for - and hiding long ugly URLs with understandable links is common practice everywhere on the web. It takes about 2 seconds to learn, and is probably among the first things users do learn. And it's not like it's a capital offense to do it wrong - this is the recommendation on how to make it best.--Amelia 00:40, 4 February 2011 (EST)

I quite agree with the sentiment that "doing it wrong" is, in this case, a pretty trivial sin. The recommendation is simply meant to provide a examples of semi-standard semi-nice way to do it. We're not declaring other ways to be wrong - just not quite as nice. It's a little like town planning - it's not about planning for next week - it's about where we want to go long term. We can even add some notes on what the syntax is and how to do it more easily (I'll take a swing at this). --Jrm03063 10:37, 4 February 2011 (EST)

I am in agreement with Amy on this one. Amy has been doing a great job cleaning up and linking new and existing cemetery pages to Find a Grave. She edits one of JRM's pages - and this need to micromanage ensues... The idea of making links "pretty" could be desired for any reference, not just Find a Grave's. However, I don't think you'd get too far recommending this as a style requirement site-wide. We are not like Wikipedia in that we allow mass upload of data, namely gedcom uploads. I don't see where Find a Grave links are any different then others (such as for example, the Ancestry links on Person:Elkanah Dyer (1)). Should we go in and "pretty" them up too? We cannot control how the links appear on the majority of pages - why nitpick these? --Jennifer (JBS66) 12:05, 6 February 2011 (EST)

There's a difference between requirements and preferences. Obviously we can't require that links appear one way or another in uploads, nor should we exert the effort to program that or police it. BUT if you're on a page, entering a link, it's an entirely different question as to what the best way to do it is. I see nothing wrong with actually expressing a preference and showing people how to implement it if they so choose. If someone doesn't want to follow it, it's not worth stressing about, but when dozens (and we hope one day hundreds or thousands) of people are willing to make these little edits, it's nice to have an actual stated standard for people to follow so there's some hope of consistency. (As much as these seem silly, minor issues now, the earlier preferences are settled on, the more pages will eventually be consistent and the easier it is for everyone.) And given that it takes all of two seconds to make links useful and more attractive (not to mention less likely to mess up other page formatting), that ought to be preferred.--Amelia 14:11, 6 February 2011 (EST)

I am sorry if I have given any offense, as I intended none. I just think that we should take the opportunity of our source pages to give examples of citations that we consider to be useful or better still, preferred (if we can decide what that is). I am asking what do folks think is the best way to do this, and offering my view in the process.

I also very much like the approach suggested by Jennifer, of using the ancestry.com practice of placing them in an attached note (as opposed to loose in the body of the citation). While somewhat more expensive as a matter of screen real estate, it has the potential to be much more useful when exported to a GEDCOM. Perhaps new users might find it simpler too. The wiki syntax approach looks nice here and conveys all the needed information but is not going to be useful when read into other genealogy software. Perhaps the wiki style makes most sense in the body of a page, while a syntax-free form is preferred in citations.

In any case, I apologize once again. I intended no disrespect to the contributions of others. I invite others to modify the content of the source page as they see fit. --Jrm03063 17:09, 6 February 2011 (EST)

I'm a bit confused. How is having the full URL in the Note field (like on the Abigail Sawyer page different than having it in the Source citation on Edward Godfrey's page (other than her name appears)? I realize that we're not talking about rules, but I still worry about having different "preferences" for different sources when those sources are similar in format, form, etc. -- Amy (Ajcrow) 16:15, 8 February 2011 (EST)

Also confused - can someone explain what the different [hypothetical] gedcom exports would look like? I think putting the URL in the note field is a lot harder to understand when in the edit mode and there is no functional display difference from just putting it in the source citation, so I'm missing the point of recommending such an approach. I've always changed such formats because I think they're awful for usability, but the gedcom issue never occurred to me.--Amelia 23:36, 8 February 2011 (EST)

As Jennifer observed above, the GEDCOM content emitted by ancestry.com places the URL in the note field and there are thousands of examples of that form. While their software is far from impressive - I doubt that the choice was capricious. I've also exported our own GEDCOMs and found that the wiki syntax obscures the URL from at least some other packages (though I can't say with certainty that the non-obscured form would be recognized). As to putting it in the body versus the note field - I would say that the body is really for an extract or quotation from the source. I would finally say that the changed format may do a better job presenting a collected citation/note than previously, so this form deserves a look on those grounds as well.

One further point. If we were to take a decision that URLs belong in a note field versus the body, that isn't a calamity for work already done. I think an agent could readily detect a stand-alone URL in a citation body and either make the change or at least direct us to the examples where a change was called for. Similarly - we could transform to or from the wiki form if that were found to be preferred. --Jrm03063 09:04, 9 February 2011 (EST)

We're getting kind of far afield, but Ancestry surely looks that way because the information from the "source" is entirely dumped into the source title field, and the information from the person-specific memo field for a specific citation is dumped into the note field. That's WeRelate's formatting choice for gedcoms, I would think. For export, everything except the source title will be in the memo field, so it's going to be the same either way.--Amelia 10:09, 9 February 2011 (EST)

I'll try to offer something more concrete as to the GEDCOM that WeRelate produces in the different cases, and we can see if we care. --Jrm03063 10:36, 9 February 2011 (EST)

The different cases of the URL in the body, in wiki, or in a note do present slightly differently in the various GEDCOM exports. So there is at least the potential that one form or another is more apt to be useful in a down-stream GEDCOM consumer. --Jrm03063 11:02, 9 February 2011 (EST)

Coming to this late. I am aggravated to find sources with an empty text box and all the text off in an attached notes, and I clean this up whenever I find them on a page I am editing. It is a maintenance headache, being very easy to delete the source and leave a dangling note since the note is often not visible when the edit screen is centered on the source citation. Unless you happen to notice the little N1 way out on the right side of the editable source citation... I have seen pages with 15-20 such notes and they are a mess when one is editing them, hard to follow as everything gets constantly renumbered when you start deleting duplicates, etc. Register my opinion strongly against putting a URL in a separate note. It should be embedded in the source citation. There are plenty of places. I have been putting it in the page field, and put the inscription, if known in the text box. I am not too worried about the URL changing since the source is titled Find A Grave, and if it changes, I suspect people will still be aware of where to find it - i.e., the url is provided more for convenience than being necessary. --Jrich 12:22, 9 February 2011 (EST)

I agree that a note is not the place for source related text - unless the purpose of the note is to allow a researcher to provide an observation about the content of the source (to note a defect for example). I have also been observing something like your practice for a while, since a URL strikes me as simply an electronic page reference - not content - but I'm trying to remain open to other ideas that are floating around. Amy thinks that a URL in the body of a citation is just fine. Jennifer pointed at an example of a page that resulted from an ancestry.com GEDCOM, where the URL is in an attached note. My observation is that some of these practices may yield more useful GEDCOM exports than others, so we should consider that (along with convenience, clarity, existing practice, and cosmetics) in trying to decide what the right thing to do might be. --Jrm03063 13:54, 9 February 2011 (EST)

I just think to expect 2 objects be created to describe one source is a mistake. In this particular case, as mentioned, I find this practice difficult to work with on the edit screen. Also, whatever may be Ancestry's practices are generally would not be a recommendation to me, if that has any bearing on what you consider useful in a GEDCOM. I consider useful in a GEDCOM that it gets there faithfully, but the exact details of where it gets put in a GEDCOM record are too subject to the whims of individual programs to carry much weight. What is useful for your software is probably awkward in somebody else's. On a bigger plane, I almost never attach a note to a source, preferring to embed my discussion in the source citation using square brackets, because they are really part of one object, and I want to reduce the possibility that one is seen, or edited, and not the other. I think the way they are displayed on the display screen like they are one entry creates confusion when you go to edit them and find they are two items. Further they are often not viewable on the edit screen at the same time, making it hard to write the note if it wants to refer to parts of the source citation. I used to attach notes to source citations, in the limited case where the discussion in the note involved comparing different source citations, and I would attach the note to both source citations, but I now generally use the Cite template to link one source citation to the other, as the new screen layout using a combined notes and sources section would cause the note's discussion to display as part of both source citations. --Jrich 15:07, 9 February 2011 (EST)

"Prettier" seems like it's being used as "substance-less", "vaccuous", etc., but style is practical. The user scans a page for useful information. The URL is useful to a web browser, not as much for a person. The answer to the upload objection is simple, the bot can add a tag to the link using the domain name of any URL, although I imagine WeRelate may have to pay for each change in code, a good reason to get it "right" early, I suppose.--Brear47 00:34, 22 April 2011 (EDT)

Hate to stir this up but after thinking through my last post, I don't believe FindaGrave is a source, it's a repository qv [HelpRepository] I've elaborated my thoughts in the Talk page for Genealogical Content.--Brear47 02:16, 22 April 2011 (EDT)

Presumably on some abstract plane, if one considered each source record in Find A Grave as a separate item, in that case, the container of those sources/records would seem like it should be a repository in the general sense. But the Sources have been set up to name all of Find A Grave as a single source, presumably since it is very much like a book of vital records written by various town clerks, collected under a common editorship. (No one ever seems to argue making the book a repository.) I think this model that a website is like a book and a webpage is like a page in a book is very common in WeRelate. Further I don't see any "practical" advantage to creating millions of source pages, each describing a single Find A Grave memorial. Are we getting stuck on the Webster definition of repository, while the WeRelate Repository (capital R) is simply the name of a type of page used by WeRelate and so Repository is defined by what that page can do, not by Mr. Webster?

On a different but related topic, my observation has been that Find A Grave memorials without photos are essentially unsourced secondary sources: you don't know where the data came from and in a few cases, I have gotten the feeling that it is based entirely on assumption, and even questioned if there was such a grave there. I know cases where the location of a grave is based on cemetery records and there is no stone, which is one reason for having a photoless memorial, and that is one thing. But if there is no indication that this is the case, I generally treat photo-less memorials about like an unsourced family tree on the Internet. --Jrich 09:45, 22 April 2011 (EDT)

FindaGrave has an intermediate level of organization, the each cemetery's collected records. Ancestry is cited in the training section on WR as an example of a repository. I get a hint that we're off-topic. I'm interested in your comment "No one ever seems to argue making the book a repository". Care to discuss at Category talk:Genealogical content?--Brear47 12:47, 22 April 2011 (EDT)

Sorry, not especially. First of all, I think Ancestry is not analogous to Find A Grave, so that example does not justify making Find A Grave a repository. Ancestry houses a collection of databases, each basically having a different purpose and organzation, and independent of each other, with more being added all the time. Find A Grave is one database. There is no place to add, say, a database of probate records to Find A Grave, whereas that type of thing happens all the time at Ancestry. Second, I think the Repository/Source train left the station when Dallan designed the Repository and Source page. While things can be changed, I think such a proposal needs to be presented in terms of specific changes to the way pages are viewed, handled and organized, and giving the practical benefits that users would experience finding, viewing and editing data, not based on abstract ideas. Thirdly, right now, cemeteries are described in WeRelate as Place pages, if at all. If you want to suggest some proposal that would somehow link cemetery Places page to Find A Grave source citations, or use Repositories instead of Places to describe cemeteries, or whatever you have in mind, write it up and post it on, say WeRelate talk:Watercooler, for comments. I probably suffer from too little vision, but I am perfectly happy with one Source page for all of Find A Grave. --Jrich 14:33, 22 April 2011 (EDT)

If it is so important to you folks to spend this much thought, time and energy haggling over where to put a link, I think you are really going to discourage the average Joe from trying to live up to your standards. Once I put a URL to a source in my desktop program and jump through the hoops to get it installed, I'm sure not going to worry over where the system puts my link. I'm not going back to each page and put a special kind of link to make it prettier. If I have to do any by hand, it will sure go in the text window so I can see it all. And I like to see the actual URL on the person page. My 2cents. --Janiejac 03:27, 22 April 2011 (EDT)

This probably should be understood as a general discussion of how to handle source/record URLs on WeRelate. As such, it's probably worthy of some careful consideration. The practice that I proposed was the one I had been using for Wikipedia, The Peerage and (to a lesser extent) Medieval Lands. A similar issue is also about to present for Transcripts, where (I think) I've persuaded Dallan to support a link for transcripted sources that would also accept a HTML anchor (For Ensign John Tuttle, see the Transcript link in the citation of Tuttle Family of New Hampshire). While there hadn't been any disagreement formerly, I respect that there likewise wasn't a lot of discussion or critical review either. [--Jrm03063.]

Amelia asked me to comment on this discussion. From a technical point of view, it doesn't matter where you put the URL. I just added URLs to a couple of pages on the sandbox, exported a gedcom, and imported it into RootsMagic to see what would happen. As expected, URLs in WeRelate notes show up as URLs in notes in RootsMagic. URLs in the text field of a WeRelate source citation show up as URLs in the text field of a RootsMagic source citation. URLs in the vol/pages field of a WeRelate source citation show up as URLs inthe page number field of a RootsMagic source citation. If you use the bracket form of the URL link; e.g., [http://url-goes-here text-goes-here] that's what appears in the exported gedcom.

From a purely personal preference, I would not add URLs as separate notes attached to the event, but instead put the URL somewhere in the source citation. Also, some desktop genealogy programs have difficulty handling notes attached to source citations, so I would shy away from attaching notes to source citations. Putting the URL in the page/volume field seems like a convenient place to put it, or you could put it in the text field.

And yes, I have supporting HTML anchors on my todo list.--Dallan 15:34, 7 September 2011 (EDT)

The reason I put forward the practice of URLs in note fields is because this is how ancestry.com formats GEDCOMs that have a source with one or more URLs. I try to give fellow software engineers credit for NOT being capricious, which leads one to believe there is/was some good reason for the practice. That said, I've never actually seen an example of a situation where this was helpful. --jrm03063 16:20, 7 September 2011 (EDT)

Clarification please! Is the current Find A Grave Citation for Rev. Edward Taylor the preferred method? Thanks.--jaques1724 18:03, 7 November 2011 (EST)

I believe so. Several approaches were explored and discussed in the context of this source, wikipedia, and others. The examples for this source follow that practice, and they havn't been challenged. --jrm03063 09:55, 8 November 2011 (EST)

I ask because on 6 September of this year, I added a Find A Grave citation for Hopestill Holley in accordance with what I thought was the an agreed standard practice (the URL in the note field). Amelia changed it (to the same format I recently used on pages for Rev. Edward Taylor and his two wives). My question to her at that time, regarding that edit, is apparently what indirectly prompted Dallan's 7 September response above. Apparently you weren't happy with the way she preferred (and which I've been using since that date). I do realize that this is a volunteer operation and that methods of recording various types of data are not cast in concrete, and that guidance is stashed away all over the site, often as preferences rather than requirements. But if somebody like me in the trenches gets conflicting guidance from two different admins, then it's incumbent on the admins to put their heads together and agree on the preferred method or that either is acceptable and then promulgate that decision. Otherwise, it gets a little confusing.--jaques1724 12:04, 8 November 2011 (EST)

I think the change that Amelia made was in agreement with Dallan's note on 7 Sept. He was saying not to put the URL in a separate note (such as N1). From the history of the Hopestill Holley (1) page, it looks like you added N1 to the FindAGrave citation (S2) and put the URL in there instead of placing the URL somewhere in the S2 citation itself. That's what Amelia changed. -- Amy (Ajcrow) 12:59, 8 November 2011 (EST)

That is correct, and I have been using the same format as Amelia did since that time. However, after two months, Jrm03063 edited a source citation which had been entered in the same format as Amelia used for Hopestill Holley indicating that it was incorrect and should be entered differently. My point is that lower level users like me should have some expectation of not getting caught between two admins who have a difference of opinion on how a certain type of data should be entered. In other wards, if Admin "A" says do it one way, I don't expect another Admin "B" to step in and edit the contributions I enter using using the format provided by Admin "A". If the point I'm trying to make isn't clear, let me know and I'll try again.--jaques1724 13:26, 8 November 2011 (EST)

Geeze - I do hundreds of edits a day and I assure everyone it is HIGHLY unusual for me to be paying attention to who did what, when, or why. I admit that the form that is shown for the examples is the one I prefer, but that I certainly put it in plain sight and sought guidance on whether that was a reasonable norm (see the discussion above). I thought we had reached agreement. Beyond that, I do not interpret edits of pages I've created as a rebuke, nor would I have others interpret my edits of pages they create as such. --jrm03063 14:18, 8 November 2011 (EST)

I am not taking it is a rebuke. I am set to watch all the pages I've contributed to: (1) to see if someone has added new content; and (2) to try and understand where I've been edited and why so that I can refine my approach to data format. My point is that if both her preference for Find A Grave (or any other) citations and yours are acceptable, none of us need expend any more effort on it. I'd much rather spend my time trying to straighten out the Rev. Edward Taylor related mess that I've been working on for the last couple of days. Still haven't decided the best way to handle the extraneous Abigail, Hannah and Anna attributed to John Taylor and Rhoda Tinker since I've got no idea how they crept in to the AFNs.--jaques1724 15:08, 8 November 2011 (EST)

Oy...this is a poster child for us getting bogged down in minutia :-) You're not caught between two admins, Jacques. Either way is fine. The "problem" that I originally corrected (as Amy points out) was to get the URL out of the separate note field. Secondarily, I prefer to hide it. Those two points I think we agreed on above (and as I remember it, we were on the same side...) and are reflected on the page itself, although the discussion is too long and convoluted to review now. There's no functional difference in the two methods, I wouldn't be surprised if we didn't think it even worth discussing.--Amelia 19:53, 8 November 2011 (EST)

Citation method [24 December 2011]

I generally disagree with the notion of adding direct-link URLs to memorials in Find A Grave because of their susceptibility to link rot. I've articulated an alternative citation strategy in the section, leaving the original in place as well. --ceyockey 11:39, 23 December 2011 (EST)

Can the id be embedded in a form that will reach the page? Are you suggesting a different link syntax, or are you saying that the bare id should be used and the user forced to search? Would you please offer an example - the "Gr" ids appear to be consistent with the memorial id. --jrm03063 12:03, 23 December 2011 (EST)

We could also create a template that uses the current URL and memorial ID. If Find A Grave's site structure changes, we could change the template. Currently, the memorial ID is appended to http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=23692408 --Jennifer (JBS66) 12:10, 23 December 2011 (EST)

That seems like a great approach - assuming that variation in the URL syntax is Ceyockey's concern. I'll create one and add an example here in a moment... --jrm03063 12:14, 23 December 2011 (EST)

I offer the Find A Grave citation in Dirk V, Count of Holland as an example for discussion. --jrm03063 12:25, 23 December 2011 (EST)

This is quite nice -- thanks. This addresses all of my concerns, which do center around URL syntax changing and breaking links. --ceyockey 13:43, 23 December 2011 (EST)

I have added a statement of origin and use to the talk page of the template. --ceyockey 13:52, 23 December 2011 (EST)

Just for convenience, this is the example: {{Find A Grave URL|61477260|Dirk V Count Of Holland}}. Perhaps the name of the template could be simplified. I just suspect people will forget if they are supposed to used spaces or not, or forget the "URL". Also, the assumption is that only a memorial wants to be linked to, I usually add links to the Cemetery page as well. Trivial I suppose, but I believe the cemetery name should be part of the citation, and if I am going to add that, why not the link to the cemetery page. --Jrich 14:06, 23 December 2011 (EST)

I agree that the template name needs to be shorter and, preferably, without spaces since most of the other templates don't use them. Same for the FaG cemetery template. -- Amy (Ajcrow) 20:49, 23 December 2011 (EST)

How about fgravemem and fgravecem for memorial and cemetery pages, respectively. This a) eliminates spaces, b) eliminates case changes, c) avoids the 'fag' issue (which would have some people snickering :( ) and d) could be used as a redirect to the current templates, so that the more informatively titled templates would be the ones maintained. --ceyockey 21:30, 23 December 2011 (EST)

I have gone ahead and created redirects Template:fgravemem and Template:fgravecem redirecting to the longer-named templates. --ceyockey 23:40, 23 December 2011 (EST)

I do agree with the shorter template titles. However, I don't really see a need for the redirects. I believe this adds a layer of confusion that isn't necessary. We could have only the fgravemem and fgravecem templates and use the {{documentation}} template to add additional details and instructions. --Jennifer (JBS66) 07:22, 24 December 2011 (EST)

It appears that adding the redirect messed up the implementation of the cemetery template. See Place:Granary Burying Ground, Boston, Suffolk, Massachusetts, United States.

Also, the de facto format for the link to FindAGrave on cemetery pages has been simply a link to FindAGrave (eg, FindAGrave: Lindenwood Cemetery), rather than links to both FindAGrave and the FindAGrave source page (eg, Lindenwood Cemetery at Source:Find A Grave. Why point users to both FindAGrave and the source page? -- Amy (Ajcrow) 08:57, 24 December 2011 (EST)

Sorry for the problem I created :(. --ceyockey 09:14, 24 December 2011 (EST)

No need to feel sorry ceyockey! I don't think it was the redirects that caused the problems that Amy mentioned. I think it was a small issue with spaces and the noinclude tags. I removed the redirects, added documentation, and added includeonly tags which should eliminate the space problems. Thank you for bringing up this discussion, it's an important one :) --Jennifer (JBS66) 09:20, 24 December 2011 (EST)

I agree with Jennifer -- no need at all to apologize! We've got two spiffy new templates to use! And thank you, Jennifer, for fixing it and adding the documentation! My apologies for thinking it was the redirect that was messing things up. -- Amy (Ajcrow) 09:22, 24 December 2011 (EST)

Oops... edit conflict :) Amy, I edited the cemetery template to match the format used on cemetery pages thus far. If we all agree the templates work ok now, we can probably delete Template:Find A Grave URL and Template:Find A Grave Cemetery URL. The two templates are: Template:Fgravemem and Template:Fgravecem. --Jennifer (JBS66) 09:27, 24 December 2011 (EST)

I just tested Fgravecem and Fgravemem. Both seem to be working fine. -- Amy (Ajcrow) 09:36, 24 December 2011 (EST)

Excellent. I tweeted on this the other day using the hashtag #werelateorg (previously used #werelate.org, but twitter didn't like the ".") --ceyockey 09:44, 24 December 2011 (EST)

Is there a fundamentally better way? [28 December 2011]

I'm thrilled with the discussion and collaboration that started with Ceyockey's original observation about link rot and quickly proceeded to development of some templates. Wouldn't it be slick though if - instead of having to put in the template reference every time you cite a page for Find A Grave - if we could define a template specifically for the contents of the page field - on a per source basis. Then, users could simply fill in the page field with the id value (for Find A Grave at least) and the redirect/link syntax noise would be hidden for most purposes? --jrm03063 11:10, 24 December 2011 (EST)

I'm sure there are things that can be done like this, and I thought that Dallan was working toward some auto-categorization procedures in the surname space. Fundamentally it is better to tag in an automated manner to the specificity that is supported by a crafted rule set, with some notion of how well a page has matched those rules, and with a bin to hold those things which have low confidence or were not able to be tagged in order that they can be manually reviewed. This would be a significant project and could not be done by editors alone, but would need coding work done. --ceyockey 16:40, 24 December 2011 (EST)

This is a good idea, but it would take a fair amount of time to implement correctly. It's the right thing to aim for long-term, because as you say, most users won't know about the templates, but I think we'll have to settle for templates in the short term.

One thing that could be done fairly quickly is to come up with a drop-down list of common sources at the top of each Source Citation entry block. Selecting a common source from the list would fill in the source title and template. But the list would have to be limited to the number of items that could fit into a scrollable drop-down list (say 50-100). How about that? Or would 50-100 "common" sources be so few as to not be worth it?--Dallan 21:31, 27 December 2011 (EST)

I'm for thinking about a few more sources and their needs, before deciding whether an intermediate approach makes sense or not. Here are a few:

• Find A Grave - best of all possible worlds. Simple integer value in the page field trivially yields a URL.
• Wikipedia - also simple, because the page parameter could just be the WP page name - with [[wikipedia|page name]] applied by the system.
• The Peerage. This is a little less handy, since it would take three parameters if you only have naive substitution available - page, id, and entry name. If a little integer math can be had, the page can be inferred from the id: page = (id+10) div 10. So it's either "id|name" or "page|id|name".
• Alden Kindred Database - this would require a page, an id, and a name. There's no apparent mapping from id to page, so the user would be stuck providing all of them. It's still better than nothing.
• Medieval Lands - this would take some thought. The content came from a word document that was labelled more or less by hand.
• Recent versions of the Oxford Dictionary of National Biography are on-line, and have an id that takes us to a url easily.

--jrm03063 22:24, 27 December 2011 (EST)

Perpective from a wiki-clueless, average user: I used to put a URL to the memorial page in my citations but have found a way that is easier for me and should work well for a viewer. I cite Find-a-grave, published at 'URL for search page' and in the window asking for vol & page, I paste the memorial #. Even if URLs to individual pages change, I don't believe the Memorial # will change. And a viewer can search for the memorial # directly from that original search page. Forgive me if I've butted into something I know nothing about! --Janiejac 22:39, 27 December 2011 (EST)

I think you're exactly right, Janie. It's important to remember that not all users are going to be comfortable with templates and pulling strings out of URLs to fill them in.

Regarding a "better way", it's important to note that not all websites use the URL to pass the search queries (which sounds like what you're depending on). -- Amy (Ajcrow) 07:24, 28 December 2011 (EST)

I think we are trying to get to a place where a user drops in a piece of logical and understandable information - such as the memorial id for find a grave instead of a URL and/or weird wiki syntax. Information like this will export nicely and re-import nicely. This probably get implemented - to a greater or lesser extent under the covers - as a template that accepts the logical information and turns it into an active URL. The rationale for an intermediate approach that exposes a template, is that at least the URL link syntax is mostly hidden and able to be updated if unimportant details change. I also agree that not all web sites are organized to allow direct access to logical pages of interest - but that isn't a reason to not support links to sites that are accessible. --jrm03063 10:25, 28 December 2011 (EST)

Similar templates for Billion Graves [23 March 2014]

With the increasing popularity of Billion Graves, I created a source page, as well as similar templates. To link to a photo page on Billion Graves, use the Bgraves template. To link to a cemetery page on Billion Graves, use the Bgravescem template. -- Amy (Ajcrow) 17:57, 25 December 2011 (EST)

I just created a template Bgraves3 which links directly to a person page, but requires two parameters from the URL as well as the name for display. Here is an example of a page where it is used. Additional documentation will follow. --Pkeegstra 14:00, 23 March 2014 (UTC)

Added a couple of recommendation statements [3 April 2015]

...to the Usage Tips section. Hope these sit well with people in general. --ceyockey 01:41, 24 March 2015 (UTC)

I'd recommend deleting the recommendation to have two source citations both for Find A Grave. I think that's really confusing, and really likely to get deleted. I feel like I have seen a dozen ways to use the primary/secondary field, and everyone seems to have their own ideas. I don't think I even see it anymore. I wholeheartedly agree with the other recommendation to explain what comes from what, though.--Amelia 05:02, 24 March 2015 (UTC)

My 2 cents... my method for citing Find A Grave here at WR has evolved over the years, and I'd venture a guess that the same is true for others as well. FAG says it best in that they are a "grave registry" - and that's it! I wish that folks would just remember that simple point, both as they create registry (aka memorial) pages at FAG and when they cite the registry here. As such, the only credible information that we might be able to get from the registry is a possible/probable verification of burial location (photo) or a lead to an original source of burial location (if we're lucky) - and yet still, as pointed out by others, the grave might be empty! Anything else posted on the page is 2ndary at best (i.e. don't cite the FAG page - go to the original source) or pure fiction at worst. BUT... that being said, I do think there is value in linking to the FAG registry page, if one exists, as their information may evolve (as does ours). As a result - I keep it simple. I use jrm's template, but instead of the person's name, I write "Grave Recorded" - since that is really all that it is! In the citation box, I note whether a photo of the stone exists and cite the actual inscription. Sometimes, I add observations (i.e. "same stone as" or "newer stone later installed by descendants"), if I think that might be helpful. Here is a simple example from two of the pages created for the Van Alst Cemetery project, Person:Albert Van Alst (1) and his wife. In this case the FAG registry pages are both wrong (see dates), but that is Find A Grave's problem. It is the inscription on the stone itself that holds value, so I followed the method above and alerted our users to the error. I don't think 2 citations are needed. --Cos1776 12:24, 24 March 2015 (UTC)

Both of your input is quite helpful. I will go ahead and drop the 'two citations' business. I am on the fence about including a transcription of the headstone, though it is not a bad idea.

Another possible approach is to actually link to a headstone picture (which would require a new template, maybe "fgravehpic") as one of only two reliable pieces of information, the other being (potential) interment in the cemetery against which the burial has been recorded. The interesting thing about the picture vs. the record is that the picture can be archived to archive.org, but the Find-a-Grave record cannot be. I tried this with the example provided: the page http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=112040387 could not be archived, but the headstone picture @ http://www.findagrave.com/cgi-bin/fg.cgi?page=pv&GRid=112040387&PIpi=82037955 could be --> https://web.archive.org/web/20150326000306/http://www.findagrave.com/cgi-bin/fg.cgi?page=pv&GRid=112040387&PIpi=82037955 . The image itself can also be archive ... original @ http://image2.findagrave.com/photos/2013/159/112040387_137082468220.jpg and archived version at https://web.archive.org/web/20150326000318/http://image2.findagrave.com/photos/2013/159/112040387_137082468220.jpg . The image and the image page were not, by the way, in archive.org before I deposited them there, so there is a concern (as with the rest of the net) that the primary information available in Find-a-Grave is ephemeral and I'd recommend putting the images into archive.org ... or encouraging Find-a-Grave to get their content in there en masse.

--ceyockey 00:18, 26 March 2015 (UTC)

I heartily agree with the idea of a template for FindAGrave images. And I often transcribe the tombstone when a photo exists. And never fail to be amused when the FindAGrave text flagrantly disagrees (with no explanation) with clearly legible text on a stone. And I disagree with the "Grave Recorded" approach, since that leaves no breadcrumbs to recover the page should the link (or numbering) ever become broken. --pkeegstra 21:12, 29 March 2015 (UTC)

I don't follow your concern. The "Grave Recorded" method still uses Template:fgravemem, it just pipes "Grave Recorded" instead of the person's name. Any concerns you might have about future broken links or numbering would have to be the same for both approaches, yet that is what the use of the template seeks to minimize. Am I missing something? --Cos1776 21:54, 29 March 2015 (UTC)

I don't understand the significance of writing "Grave Recorded". Isn't the implied by saying there is a link to Find A Grave? So I put the header of the page as Find A Grave labels it, even if they spell it differently than the stone. And while the purpose of the template is to make the link more robust, certainly unexpected changes could happen (especially since it is now controlled by Ancestry) so I think pkeegstra makes a valid point. --Jrich 22:29, 29 March 2015 (UTC)

No significance other than noting that Find A Grave is just a grave registry, and I'm not sourcing the name as entered by the owner of their memorial page. That name is often embellished or different from what is inscribed on the stone or changed by the owner of the memorial at any time. I'm sourcing the static stone inscription and location (which would be in line with Ceyockey's ideas for citing the photo of the stone - I like those!). As for the robustness of the link, of course it could break in such a way that is outside the safe guards of the current template, but I was only speaking in the context of using the template as it currently is. My point was simply that if we are using the current template, piping different text doesn't have any affect on the way the template works. I can pipe "Grave Recorded" or "Jane Smith" or "Memorial #3009781" and it is going to work the same way. --Cos1776 23:17, 29 March 2015 (UTC)

Following the chatting above about "grave recorded" and use of a person's name in the fgravemem template, I lit upon a third option which references a picture without creating a picture-related template. For instance, at Person:Guy Logue (1) I used the construct pic 82202772. The page I used as the reference was http://www.findagrave.com/cgi-bin/fg.cgi?page=pv&GRid=73311791&PIpi=82202772 , which is the "Photos" tab accessed from the main memorial page which the fgravemem template links to. I've also taken to putting this page into Internet Archive, which handily preserves both the fgrave page and the embedded photo; above I noted that the memorial page itself resists being preserved in this way. --ceyockey 19:19, 3 April 2015 (UTC)

Why change name to Global? [29 May 2017]

I can't see a legitimate reason for this change. When I go to Find A Grave, the only name on the page is "Find A Grave". The only place I see the term "Global Find A Grave" is on Ancestry, used for their index of non-burials, etc. The original source is still cited as Find A Grave.

Why make a change that makes this source much harder to find for all users and with no prior discussion or notification?--Judy (jlanoux) 15:28, 29 May 2017 (UTC)

I agree. First, there is no place 'Global' so there is this big red text in the middle of the header. Second, the specs say that websites are titled with the title field only.

• An authored source = Author field + Title field.
• A geographically-focused set of records = Place field + Title field.
• Websites or works without a known author that are not specific to a region = Title field only.

--pkeegstra 17:04, 29 May 2017 (UTC)

P.S. Please don't construe this as a suggestion to create a placepage 'Global'.