Source talk:Find A Grave

Topics


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)