What should we think about before expanding on the usage of free-space profiles for sources?

Question

Hi WikiTreers,

Part of the reason that we pushed to settle on our sourcing style last month was so that we could lay the groundwork for more uniform, simple recommendations for better sourcing, possibly by adding more user-friendly tools.

First on this agenda, I think, is to see what we could do regarding free-space profiles for sources.

We've had a simple page recommending them for years but relatively few members have used them. Rick Pierpont, however, really ran with the idea and elaborated on the possibilities.

Rick has taught his methods to some other WikiTreers and they have built a library of sources at http://www.wikitree.com/wiki/Category:Source

We could be doing a lot more to make WikiTreers aware of that library and make it easier to add to it.

I do think that profiles for sources -- like this one http://www.wikitree.com/wiki/Space:Encyclopedia_of_Connecticut_Biography -- are a real public service and can be handy on WikiTree.

They can list multiple places where the source can be found, and this list can be updated whenever necessary, without needing to update individual profiles.

Moreover, source profiles can be used as mini-project pages if members want to collaborate on creating profiles using a given a source.

To facilitate creating these profiles we could have a special form like the ones for creating free-space projects, one-name studies, etc. It would have standard text and categorization. We might even link to it from a pull-down menu, e.g. Add > Source.

Before going forward with this I wanted to make sure that others think this is a good idea, and settle some things about the formatting.

On Rick's source profiles he conveniently gives copy-and-paste examples for usage. Great.

A question mostly for Rick: Is there a reason we couldn't change these examples to use the now-clearly recommended method on http://www.wikitree.com/wiki/Sources for repeated usage of the same source on the same profile? That is, recommend the named ref method rather than span and id tags.

We use span and id tags on GEDCOM-imported profiles and they are not officially recommended against, but as explained on http://www.wikitree.com/wiki/Sources_Style_Guide I think we should try to fix how they're done in GEDCOM imports in the future and not encourage further usage.

I also want to ask about the categorization. Hopefully some categorization project members will pipe in.

Rick has categorized, for example, Space:Encyclopedia_of_Connecticut_Biography under [[Category:Connecticut]] and [[Category:Source]].

I think the regional categorization is clever. Using the same regional hierarchy that's used for other purposes reinforces it. Do others agree?

Regarding [[Category:Source]], I don't remember if this was discussed, but I assume Source singular was used because the more conventional Sources plural was being used for the help pages on Sources.

To fit with our current categorization style, ideally, I think the help pages on sources should be moved to [[Category:Sources Help]]. That would free up [[Category:Sources]] to be used for sources. But ... I feel bad even suggesting this since Rick and others have categorized so many sources under [[Category:Source]]. But maybe if other changes on those pages are being made it wouldn't be such a burden? I don't know.

Other thoughts?

Onward and upward,

Chris

Comments

I like the Named=xyz system and am tempted to use it even on refs which aren't used more than once on a profile just so it would be easily available to use.  BTW, I've taken to having a Word Document up full time with my own templates, categories or boilerplate available for cut and paste.  I think it's easier to have it off the net so I don't have to worry about saving profiles, etc. when working on WikiTree.  It's a;so useful for spell checking.

---

Dave, I also do everything offline, for all the reasons you mention. Also, by uploading all changes to a profile at one time, there is only one new item in the Changes Tab. This makes it easier for others to see the changes.

The alternative, is to do everything online, doing multiple saves so no information is lost. This can easily place 10 or 15 changes in the Changes Tab, making it difficult for others follow along with the changes.

Answer 1

Your whole Question/post is too confusing to me and I am unsure about how the whole thing would work. If it is indeed simpler then I will support it, but I fear that all you will end up doing is to drive away those who are trying to add sources with all of these changes.

Comments

Dale, I think there is room on WikiTree for everyone to add sources using whatever method they find easiest. This doesn't mean that we can't offer other methods that have advantages.

---

Rick, I am not debating your statement about adding sources however you want, but even disagreeing with Chris on the method he is pushing I do feel that span tags should be recommended against because there are just too many people on here who remove them because they do not understand them. I do understand span tags but I remove them from the profiles I manage to help make sure that the sources remain and are not removed because other well meaning folks do not remove the part that is not "recpmmended".

---

Span tags are on the Recommend List. They are also used by WikiTree when importing GEDCOM files. This has been true since the beginning and still used today. So I am not advocating something new. I would like the Style Guide to be expanded to better support Chris' original post above, to better describe how WikiTree operates, and for other reasons too.

---

They are at this time, but Chris wants to discourage their use. See "We use span and id tags on GEDCOM-imported profiles and they are not officially recommended against, but as explained on http://www.wikitree.com/wiki/Sources_Style_Guide I think we should try to fix how they're done in GEDCOM imports in the future and not encourage further usage."

His words not mine.

Answer 2

I feel like Dale, I need to see it ...not have it described. I do think the Rick and associates "Source Library" could be included in the "Tree and Tools" button on each profile.

Answer 3

I really like the idea of using Free-Space pages to share information about sources. Being able to add Tags and Categories is a great way to spread the word about a source. I've had some frustration with Categories, but I do think Categories are necessary and their use should be expanded to include sources.

One problem with Categories, related to sources, is the limited "list" format used by Categories. As an example, using Categories it is not possible to create a list that looks like this: http://www.wikitree.com/wiki/Space:Sources-Vermont This forced me to make my own lists of source free-space profiles. In this way, the Category became a "Label" that was applied to the Free-Space page. Labels are usually singular, not plural. A Free-Space page could then be labeled anything: Cemetery, Town, or Source.

Tags are another great feature of WikiTree that can be used on sources too, if Free-Space pages are used for sources.

One problem related to sources and Free-Space pages is "Bloat". Adding more source information (required for links to free-space pages, etc.) increases the amount of bloat within the biography. Bloat is bad enough with the "inline citation" format used in the style-guide. Adding Free-Space information makes the problem worse.

A normal book citation includes Author, Title, Publisher, and page #. Using Free-Space pages for sources expands the amount of information to include the source free-space page link. Also, other information is usually included: actual source page link (Google Books, Archive.org, etc.) and sometimes quotes for the source.

That is a lot of source information, which is great. It does, however, increase the amount of bloat. Some profiles I edit have more source information than biography. Here is an example: http://www.wikitree.com/wiki/Pierrepont-26 While that may not be the best example of a profile, it does show how source information can be added with the minimum amount of bloat.

Chris, I misread your post last week about the subject of the Style Guide and citations. I thought you were including inline citations as one of those "alternative methods". When I realized my mistake, and then saw all the responses, I decided to step out of the fray.

The span id solves the bloat problem. Most profiles already use span ids, and all imported GEDCOM use them too. The Style Guidelines do not change these things. However, the style guidelines could easily be expanded to include span id. Once people learn about span id, it will be easier for them to clean up those ugly GEDCOM created profiles. It will also make it easier to use Free-Space pages for sources.

For those that haven't seen it, there is a YouTube video that covers the basics of using a Free-Space page as a source in a profile: https://youtu.be/U63ZYOPVS8o

I am sure there is more to be said about using Free-Space pages for sources. I hope people ask questions. There are many examples already, most of them are here: http://www.wikitree.com/wiki/Category:Source

Comments

Rick, Your example profile is a pre-1500 profile and as such I could not see how the sources work without a pre-1500 badge. because I could not look at the edit page and see how it is done I can only see the result so for that reason I still do not understand how using Free-Space profiles is going to help with sourcing other than to provide a list of where to locate some sources. You said that it would increase bloat when using it for inline sourcing so for that reason alone I would not support it. We already have other members who dislike the amount of bloat that is in use for the recommended methods. With the limits of my computer system, vision, and hearing problems a you tube video is worthless to me for seeing how to do it, I need a profile that I can see the edit page if I am to ever understand this method and form an opinion on it.

---

Dale, Here is another example: http://www.wikitree.com/wiki/Pierpont-97. Sorry, I wasn't thinking about dates. I am not sure what you mean by "help with sourcing". Using Free-Space pages for sources is a way to collaborate on sources: share sources, find sources, document sources (revisions, multiple volumes), source locations, etc. These are things that most people are not doing. Source citation is a different subject (although it is certainly related). 

If people want to simple add a source or citation, that is great. The problem is that most people don't know what sources are available and how to find them. WikiTree can really help with this. 

There are many good sources available for free. If I see a source in a profile, I probably won't look any further. If they include a page link, I might look at that one page. It takes extra work to learn about the source, how many revisions were there, how many volumes, did the author publish other works, what are the author's credentials, etc. Some online books are better at Google Books and some are better at archive.org. They may have a better scan, better OCR, or a better viewer. Then we need to add Tags, Categories and probably organize them using other methods too. Gathering this information takes time and the willingness to do the work. Not everyone will want to do this, and that is fine. The important point is that we collaborate and learn from each other. Using Free-space pages for sources is a great way to do this.

The problems with bloat have been solved. I tried to show an example, using the method WikiTree has used since the begining. It is the use of inline citations that causes bloat, not the use of Free-Space pages for sources. In fact, I have seen people delete source information to reduce the bloat in their inline citation.

Using Free-Space pages for sources is not difficult, but it is not as easy as a simple inline citation. I don't think anyone is implying otherwise.

---

Thank you Rick,  I can see only one "problem" with your example and it is caused by the line in the original question by Chris

"We use span and id tags on GEDCOM-imported profiles and they are not officially recommended against, but as explained on http://www.wikitree.com/wiki/Sources_Style_Guide I think we should try to fix how they're done in GEDCOM imports in the future and not encourage further usage."

I do believe that the span tags are confusing to most and are part of the reason that some remove sources and agree that they should be recommended against and that the pages that list links for sources are good, but it is His line that we would only need to update the free space page when changes are made and not the individual profiles that is the confusing part. The way I see it, and I may be wrong, is what he is proposing is going to add a lot more work for everyone.

---

Hi Rick,

In your Pierpont-97 example you use both named references and the internal link method.

For example, here's the first time you use a source: <ref name=TBC>[[#TBC|Barbour Collection]]</ref>

Here's the second: <ref name=TBC/>

Then at the bottom you have:
<span id='TBC'></span>''[[Space:The Barbour Collection|The Barbour Collection]] of Connecticut Town Vital Records''. Vol. 1-55. 1994-2002. - White, Lorraine Cook, ed. Baltimore, MD, USA: Genealogical Publishing Co., 1994-2002.

That's a lot of complication. You could remove one layer of it by putting the entire citation in the first ref, i.e. by just using the recommended method.

We really need to find ways to simplify and unify our methods. That's what the discussion last month was all about.

There's a parallel problem with what you're doing with categories. If categories on WikiTree don't make good lists, we need to fix that. It might be frustrating to wait for that fix, but in the meantime we can't officially endorse doing something completely different, e.g. making lists manually and using categories as labels.

What I'm getting at is that before we could recommend that others follow your lead, we'd have to bring what you're doing in line with our other recommendations.

Sure, we can discuss changing our other recommendations, developing completely new systems, etc. I'd certainly rather not. I'd rather think we could just move forward. But if we're talking about bigger changes, what do you think of the thread with Rob below, or the comments from this newt Jamie Estill?

Chris

---

Hi Chris,

Yes, I agree, using inline citations can be expanded to include a lot of information, just as you suggest. Inline citations, and the other Alternative Methods, do the job. We can't argue that they don't. The only argument we can make is what is better.

For me, what is better, is whatever makes the profile easier to edit now and in the future. Seperating complex source material from the biography seems an obvious first step. This makes both the bio and source easier to read and edit. (I am not saying it is easy, I am just suggesting it is easier.) 

Some biographies have become just a few inline citations with a bit of text inbetween (dates, etc.). Using external links and internal links in these inline citations (as we are also suggesting) can double or triple the amount of text in the biography. Much of this additional text is unreadable to many people on WikiTree, therefore the entire biography section becomes unreadable.

Editing a merged profile is so difficult, most people won't do it. How do we merge two inline citations with similiar information? Delete one? Try to pick out the best info from each? I don't know. I don't think I have ever done this. Most profiles on WikiTree don't use inline citations. In cases where two profiles are merged, it has always been easier to move the source material to the bottom and merge (the much smaller) citations in the bio. Then, the final step, is to merge the source information together at the bottom. 

There is a very long Wikipedia article about citing sources here: http://en.wikipedia.org/wiki/Wikipedia:Citing_sources Here it describes the problem: "Inline references can significantly bloat the wikitext in the edit window and can become difficult and confusing."

There are other problems with inline citations too:

1. They don't support multiple page references to the same source.
2. They discourage adding more source information (quotes, free-space links,etc.) because it increases the bloat.
3. They don't work in all situations ("See Also").
4. Most profiles on WikiTree don't use inline references.
5. Most new profiles don't use inline references.

I don't think there is a reason to overhaul the Style Guide, but I do wish it could be expanded to include span id, the most prevalent sourcing method on WikiTree. 

Rick

---

Rick, I don't get to write as many biographies lately, but when I do, I always add inline references.  In most pre-1500 biographies inline references are essential to deal with conflicting or disputed information.

---

I agree, these references are essential. We are only discussing the format of these references. If the inline reference is kept small, they can be very easy to use. As the text in the reference gets large, the biography becomes very difficult to read. The more information you include in a reference, the better it is to deal with conflicting or disputed information.

The suggestion Chris is making in his original post may significantly increase the amount of text in the reference. I think it will also help deal with conflicting or disputed information.

How do you handle multiple references to the same source?

---

To be clear, Rick, this is the discussion we had last month. We're going backward instead of forward. It may be necessary, but it definitely slows down any progress.

http://www.wikitree.com/g2g/214184/specifically-recommending-alternative-sourcing-methods

---

There was no discussion about using Free-Space pages for sources at that time. Also, at that time, I had no idea that you were classifying the main method of WikiTree source sitation as "Alternative". I suppose that was my mistake, but WikiTree still hasn't changed in this regard. WikiTree still creates profiles that are contrary to the style guide.

I view adding both, span id and source free-space profiles, to the style guide would be a step forward, not backward. It would also bring the style guide up to date with the way most profiles are created on WikiTree.

I think the next step is for people to start using Free-Space Sources, then discuss the problems here on G2G, develop solutions, and then modify the style guidelines to support these solutions.

Answer 4

Re named refs.  Usually a link to a book is no use by itself.  I want to give a page number, and usually I want to give a direct link to the page on archive.org or Google Books.  Named refs don't help with this.

What I would do is

== Biography ==

Blah blah.<ref>[[Space:Book|Book]], [url/page/17 p. 17].</ref> More blah blah.<ref>[[Space:Book|Book]], [url/page/35 p. 35].</ref>

which would look like

Blah blah.^[1] More blah blah.^[2]

1. Book, p. 17.

2. Book, p. 35.

Or maybe

== Biography ==

Blah blah.<ref>Goode, [url p. 17].</ref> More blah blah.<ref>Goode, [url p. 35].</ref>

== Sources ==

<references />

* Goode: [[Space:Book|Book]].

which would look like

Blah blah.^[1] More blah blah.^[2]

== Sources ==

1. Goode, p. 17.

2. Goode, p. 35.

* Goode: Book.


Links and span-tags could be added to "Goode" but I think that's overkill.  A system that uses span-tag anchors should also work without them (especially as they don't work brilliantly anyway).

Most of the time, I don't want to have to chase through a free-space page that I've seen many times before, when I'm already familiar with the source, and all I'm trying to do is look at what the source actually says on the point in question.

Comments

Hi RJ,

Can you expand on this: "especially as they don't work brilliantly anyway"?

You make a good point that often the internal link isn't really necessary.

Thanks!

Chris

---

The anchor can't be positioned at the top of the window if there isn't enough page below it to fill the window.

Which means you can't rely on the link to identify the item, you have to make the connection by the visible labels.

Answer 5

Chris,

Allow me to restate a suggestion from some time ago:

1. Create a distinct namespace for sources.

2. The namespace should have dedicated fields for essential citation elements. (author, title, etc.) and possibly a field for a pre-formatted 'fill-in-the-blanks' citation.

3. The .tpl file for source pages should have a 'what links here'/'inbound links' accessible to all users, not just leaders (currently Rick and others manually add it as it is not part of a freespace page's .tpl)

Reasoning:

A) It makes it clear when editing a profile that a link points to a source [[Source:My Dog Tulip]] (a memoir by J.R. Ackerley) instead of something [[Space:My Dog Tulip]], (someone's family pet).

B) Looking to the future, distinguishing sources from all the other freespace pages will make it easier to eventually add some sort of 'source lookup' capability. Likewise dedicated fields for essential citation elements are useful for efficiently searching a particular source. If a tool/widget to drag/drop a citation to a profile is ever going to be developed it will need to know what info to copy (since a source page has much more information than just a citation)

C) I believe source pages, similar to category pages, should not have the privacy restrictions that freespace pages do. (A sources 'watchlist' aka 'library' of frequently cited works might be useful for a future source widget/tool)

D) Adding the 'what links here' to the .tpl can be a helpful tool in identifying potential duplicates or profiles that may be connected (unless the source is a large collection like a Census year)

I also think that if we expand usage of source pages (whether we simply expand the existing usage of freespace pages or create a new namespace as I suggest) there are some things that I would say should be specifically addressed in any guidelines that are developed, including:

• How do we distinguish when two works have the same title? An incrementing number, year of first publication, author surname? Do we want full titles (some are very lengthy) or do we use a work's short title (possibly with some other info such as author or year)?
• Do we want to omit leading articles (a, an, the) from the page names so that the majority of sources are not clustered under "A" and "T", do we encourage people to manually categorize A Book as [[Category:Source|Book]], or do we just accept that potentially thousands of works will be categorized under 2 letters.
• What types of sources do we want to have source pages for? Only published works and collections applicable to many profiles or 'any' source (including things like family bibles, letters, etc.)? If we don't establish clear guidelines on 'scope' some people may ignore a 'roll-up' page like Space:United States Federal Census and start creating pages for each year, each state, each county. (or do we want that for some reason?)
• Should individual volumes or editions have separate pages or should they be lumped together on one page? (Keeping in mind that these may have different authors, editors, and publication years.)
• Capitalization of titles - There are as many variations in how to 'properly' capitalize a title as there are style guides. Since page urls are case sensitive there should be one chosen standard to avoid duplication. To illustrate each of the following use a different style: 
  • A General Index To The Magazine Of History With Notes And Queries;
  • A General Index to the Magazine of History With Notes and Queries;
  • A General Index to the Magazine of History with Notes and Queries;
  • A general index to the Magazine of History with notes and queries; or
  • A general index to the magazine of history with notes and queries.

Comments

I stand with ROB [edited] on this one.

AND: Please please please please work with Dallan Quass at WeRelate.org to import or otherwise share/copy the amazing Source namespace (and its pages) that that community spent years working on.

It's absolutely amazing and would be an absolute shame if wikitree recreated the wheel that that community spent years working on. I know from personal communications with Dallan that he would be open to such collaboration.

---

Jillaine, I know Dallan pretty well and have talked to him a lot about collaboration, most recently at RootsTech a few weeks ago. You can suggest this to him. He might suggest that you try to win over the WeRelate community.

Rob, I appreciate the arguments for a Source namespace, and this might indeed be the best approach if we were starting from scratch and resources weren't limited. But everything is, of course, limited. I know your time is limited these days. :-)

Although there are many points in favor of creating a new Source namespace, there are also points in favor of free-space profiles. Many of the features we've worked to develop over the years could be useful, especially for collaborations on using sources. Activity feeds, Watchlists, comments with e-mail, linking G2G questions. Definitely the images. Maybe even the privacy controls for certain modern sources. And there is our matching system for suggesting duplicates before creation.

Regardless, as I mentioned, we're not starting from scratch. The theoretical benefits of a new namespace can't just be weighed against the existing benefits of the current system. The current system is the current system. The benefits of adding a completely new system have to be overwhelming to justify the added complexity.

I'm sorry if I sound dismissive. I do really respect you, Rob, and that's why I took the time to give it some fresh thought (which I did, even if it doesn't sound like it).

---

Hi Chris

Just for greater clarity, my proposal is to more-or-less duplicate the entire existing Space namespace, freespace tpl, and any underlying code related to Freeespace pages as the basis of a distinct Source Namespace (not to code something entirely new and different from scratch). Lots of work certainly, but most of it is essentially copy/pasting and then testing to make sure you didn't forget to copy/paste something. This creates a start state for sources which can then be tweaked or enhanced over time.

As Rick and others have already shown, and as you listed above, the existing functionality of the freespace page works and has some great benefits. Taking that as the baseline and extending it with a couple additional fields relevant specific to sources in the underlying table and in the tpl will, I believe, greatly simplify the future enhancements/widgets for sources that you have discussed at various points.

Imagine with me for a moment - you are on the editing page of a profile. you click a button (possibly on the WYSIWYG editor) and you are presented with a pop-up of your 'source watchlist', not every source on Wikitree, just the ones you are currently working with (PGM project members would no doubt have The Great Migration, while the Quebec Project members would almost certainly have DGFA in their list, etc.). You scroll through your list (sortable by author or title using the added fields) find the source you wish to cite, press the 'insert' button, and the pre-formatted 'fill-in-the-blanks' citation (from the field in the sources table), complete with <ref> tags is pasted into the bio and the pop-up closes. You can now make any needed little changes to the citation text (page numbers, annotations, description of the specific record, etc.)

Obviously this imaginary new widget/tool would require effort to create and integrate, but it can be created later. Such a tool is however enabled by having a distinct list of sources with a few additional data fields.

P.S. you don't sound dismissive.

---

Oh, hmmm. Now I'm following you better, Rob.

This is something to think about more. It would be a lot of work. It's not just a matter of copying the systems for free-space profiles and making changes. It's all the other WikiTree systems that interact with free-space profiles and would now need to interact with source profiles. Activity feeds. Following feeds. E-mail updates. Merging. Watchlists. G2G. GEDCOM import and export. Search.

Once everything is all implemented, we end supporting a lot more that has to be maintained, tested, de-bugged, etc.

But it may or may not be worth it. I definitely see what you're saying about a Source Watchlist.

Rob, what do you think about what Jillaine is saying about WeRelate?

Collaborating with WeRelate could just mean imitating their structure, if Dallan doesn't mind, and could mean copying their source pages -- if we were to license content in the new namespace with Creative Commons.

That's a big "if". Switching to a CC license for this area would probably require removing all the privacy controls. I know you think that would be a good idea, but it would add a lot of complication.

And what do you think about Jamie Estill's suggestions below?

---

Arranging to import the WeRelate sources would potentially save tons of startup work and as Jillaine points out, why reinvent the wheel if we don't have to. Obviously if we are importing their data there will be some manipulation or omission required. For example:

• WR uses separate place and repository namespaces that would need to be stripped to the 'text-only' and concatenated into the text (or at least I don't think you want to recreate all the additional namespaces)
• The categories linked to the sources may not follow the same naming conventions we use - it might be simpler to strip them out and 'start fresh'
• The WR 'coverage' fields, unlike the roughly analagous fields on our existing freespace pages, allow more than 1 location; more than 3 associated surnames to be 'tagged'; and a date range. There are multiple options on how to 'solve' this difference: simply ignore the fields, allow more tags on our end, import only the first X values (dumping the rest into the text if desired)
• On WR the formatted citations appear to be built from the individual data elements depending on the source type - this might require much more complexity to implement than my suggestion of having one field with a 'fill-in-the-blanks' citation. If we don't want the added complexity it should be easy enough to concatenate the fields into a single field on import which can then be adjusted/corrected as needed.

We could also add an interwiki link back to the original source page on WR.

Jaime's suggestion of "a central reference URL" is, in a way, what we are already discussing - a separate page that describes a source that can be easily linked from other pages. Where I have suggested adding a few additional fields that give an almost rudimentary description of a source, Jaime's suggestion, as I interpret it, is to capture and store a much more 'complete' description and with particular attention paid on conforming to a particular standard.

---

Dallan (of WeRelate.org) gave us permission to share this email he sent to Chris and me in response to my asking Dallan about what it would take to share their Source namespace data with wikitree:

On Wed, Feb 17, 2016 at 4:34 PM, Dallan Quass <> wrote:
> It would be pretty easy to share the source namespace.
>
> Chris, the source pages are part of the standard wiki xml page dump if
> you're interested. WeRelate has around 1M source pages. The portal (not well
> maintained but hopefully will give an overview) is here:
> http://www.werelate.org/wiki/Portal:Source
>
> An example source page is: http://www.werelate.org/wiki/Source:Find_A_Grave
> You can see the raw page text here:
> http://www.werelate.org/wiki/Source:Find_A_Grave?action=raw All of the
> source pages have an embedded xml "island" that contains the structured
> fields.
>
> Here's another example:
> http://www.werelate.org/wiki/Source:United_States._1930_U.S._Census_Population_Schedule
> and the raw page text:
> http://www.werelate.org/wiki/Source:United_States._1930_U.S._Census_Population_Schedule?action=raw
>
> I'm happy to share the xml page dump with you if you want it.
>

---

I've been fretting over this the last two days because it feels like something we should do. It feels like the right way to do sources.

But I'm not sure it would be practical.

First, it would be a huge amount of work. To do it right -- and that's what we're talking about -- we could hardly make progress on any other features for months. And it would always be something we would have to carry. It would add something big to what WikiTree is and how it works.

It would be something good, I think. Maybe something very good. But we're a small organization and can only do so much. We need to focus our very limited resources.

Second, the benefits would be mixed. I don't think everyone in the community would love this. Many people are happy to copy and paste the citations from FamilySearch, or put in a simple link to Find-a-Grave, or to a Google Books page, or whatever.

For example, let's say we have pages like http://www.werelate.org/wiki/Source:Find_A_Grave in our own Sources database. Rather than people formatting their own link as a source, they'd click the citations widget, search for Find-a-Grave, enter a few key pieces of information, and it would insert a formatted citation. We'd work to make it user-friendly and hopefully it would be. But the end result wouldn't be that much better or easier than a simple link to the Find-a-Grave page.

I think the most compelling reason to have pages about sources on WikiTree is so that they can be collaboration hubs. If members want to work together to evaluate and use given sources, it makes sense to have pages for them, essentially like free-space project pages. Source project pages would be ideal, but creating free-space pages works.

(Some people in this thread may have misinterpreted my original post. Maybe it wasn't well worded. I didn't mean to propose that we move all sourcing to free-space profiles. I just want to make it easier to create these separate pages when members want to do it, because they have extra information about a source or want to collaborate on it.)

I'm really leaning against a new sources namespace. Rob and Jillaine, if you want to continue this, maybe start a new G2G thread outlining the pros and cons. If a lot of community members would be excited to start a fork of the WeRelate sources I could put more thought into it.

---

(One would not have to cite the Source namespace pages; they could serve the exact same purpose as Freepage source page. 

It's their content i think you should nab, Chris. So we don't have to recreate a freespace page for every source. It's SUCH a rich and existing resource. 

Isn't there a way to nab the content for the equivalent of what you want to see via the Freespace pages?

 

Answer 6

Although Rick has done a great job at collecting all these sources, I think the principal basis for adding a source has been availability and not quality or reliability.

For instance the page of English sources http://www.wikitree.com/wiki/Space:Sources-England has a number of links to the early peerage books of Burke and Debrett.  They are notorious for publishing genealogies without doing any checking and consequently although they may be an OK source for families contemporary to the date of publication they are an extremely poor source for earlier periods.  Half of the families erroneously connected to Norman times probably have their origin in one of these publications.

I just have a concern that if something like this list becomes an official or semi-official Wikitree site than people may think that a source in these lists is a recommended source for the profiles they are creating or editing.

Comments

John, I think the problem you describe will exist whether we have source pages or not - the advantage of this method is that notes about the overall reliability of a source or even specific errata can be added to the page directly to help warn/educate people citing a given source and to save future profile editors having to figure out if a given source is a known problem.

---

Great point, Rob.

One of the things I like most about the idea of using free-space profiles for sources is that they can become collaboration hubs. They're not just for communicating information about a source. Free-space profiles, like person profiles, are built for collaboration.

---

Thanks Rob and Chris, I definitely agree that a free-space page for a profile can point out any issues that may exist with some sources, perhaps even with links to expert review.

Answer 7

I'm all for simpler sourcing!

What I'm not sure about, though, is how using free-space profiles would simplify sourcing. It does simplify adding the right source verbiage to a profile, but there is still the concern with someone actually taking the time to look for source material for the John/Jane Doe they are researching, and then looking to see if it already exists somewhere in a free space profile. I suppose, if someone were from Vermont, for example, they could go to the Vermont Source page and peruse the sources there for mention of the ancestor, but that is never my first thought (I doubt I'm alone in this view).

I haven't used the sources free space page even though I've used sources mentioned there for a simple reason: it requires linking TWO, rather than one "sources". For example, I usually like to include a link to the actual page within the source in which the ancestor is mentioned. If I were to use the free-space profile source page as well, I would also have to link to that page. It is duplicate work for me, from what I have seen so far.

I'm sure they have potential; maybe I'm just not understanding how they would fit into my workflow when fleshing out a biography with sources. More education about workflows involved with looking for, finding, and then documenting sources would be great.

Comments

I think your description is accurate. When adding sources to a profile, most people are using cut-n-paste to copy the source into the profile. This may be what you are doing too. I have all the extra free-space information already formed elsewhere*, and then simply using cut-n-paste to get it into the profile. It is certainly more information, but it is the same cut-n-paste process.

 

* This is included in the Free-Space profile, with all the other information about the source.

Answer 8

I would like to see a linked data approach to sources and citations. Similar to URLs like http://www.wikitree.com/wiki/[SURNAME]-## for people, having a central reference URL like http://www.wikitree.com/resource/[URI] would allow for linking to resources across the site. These resource URLs could even point to other public URIs like DOIs(https://en.wikipedia.org/wiki/Digital_object_identifier) and handles references (https://en.wikipedia.org/wiki/Handle_System). This would greatly add to the utility of the concept of source and reference, and would allow for extremely high-quality data provenance that can not be found on any other public genealogy web sites.

Starting with sources would be good start on linked data that solves an existing problem around the current state of sources as free text. The metadata for resources could be standardized with the typical metadata used for references (ie. Dublin core). The code to implement this could be written in a format that is generic and ontology driven. This generic format would allow for expansion to other concepts (location, event etc). The user interface could also be simpler than the current state, and it would even be possible to write simple code to import metadata from public resources using web services and direct import from formats like bibtex.

The linked data approach would also facilitate web services around wikitree data that expose data in standard formats, and this could allow for wrapping other GUIs around wikitree data via open APIs. 

I also think that there are opportunities to learn from semantic media wiki in implementing this approach. This could be rolled out as an extension of the current state that does not lose any of the current free text references. Enrichment of the current free text references could be enhanced with semantically linked wiki tags. Reconciliation of references in GEDCOM imports could follow a similar format as what is done for person merging and reconciliation.

I have had experiences working with linked data, archival storage, ontologies and could volunteer to provide some help.

Comments

Ok, now could we have that in English instead of computer speak? Afraid I'm not that tech literate.

---

Don't reinvent the wheel. Make it easier for users. Make the data linkable out to other programs (like Gramps).

---

I'll take your word for it that this would make it easier for users. I'm all in favor of that. But for those of us who do not know what metadata is, or DOIs or URIs, you will need to be a bit more explicit in explaining how your suggestion would work.

---

DOIs and handles are ways to provide permanent addressees for digital resources. Have you ever linked to URL for a genealogy resource and come back 10 years later to find a dead link?

URIs are just a standard way to provide an identifier to a resource. URLs are a type of URI.

Metadata is the information about the resource. Things like Author, Title etc. Adding structured metadata prevents you from having a lot of free text that can not be interpreted out of context.

As an example of ease of use, instead of manually typing the full reference over and over for the way citations currently work, you just use a referral link. For generating the information that the link points to, instead of manually entering in a lot of redundant free text, you could use auto-import functionality that reads RDF data or MARC formatted data.

For example, consider of all the manual effort that is pushed onto users to manually enter metadata about the Encyclopedia of Connecticut Biography. A better user experience would be to point to the URL at https://openlibrary.org/books/OL7020841M/Encyclopedia_of_Connecticut_biography and code at wikitree would be able to interpret the RDF or JSON links in the bottom right hand corner. RDF and JSON are basic standards for exchanging computational information, and it is pretty ease to write code to parse this information. The standards for reference metadata exchange have been around for decades so there would be no need to reinvent any standards for the exchange and storage of this information.

Following a semantic media wiki approach. This functionality could be made to set on top of the current wild-wild-west of free text and add some computationally interpretable structure to the source data. In the end people would need to do less work to get better results that are of a more archival quality.

---

Jamie, it's great to have someone like you participating. Someone so technically-adept and experienced in Wikimedia projects. I hope you continue to participate on WikiTree. You'll find our community doesn't move very quickly on technical changes, but there is a constant evolution, hopefully in the direction of progress. You can help shape that direction if you stick around.

Be sure to see Rob Ton's post above, though you may be discouraged by my answer. His suggestion is less radical than yours.

Answer 9

I have only dabbled in Rick's sources he's set up, but I really like what I see. I think there is a lot of potential in using Free-Space pages for this sort of thing. I just saw a question come up about the reliability of a source, and using FSPs for sources gives us a way to link those questions to the source page, too, so others can quickly see a discussion of whether the source in question is one they should use concretely or more as a guide toward finding better sources, which of course could also be referenced on that source page. The more I dig into it, the more I like where it's headed. And adding it to the drop down menu definitely seems a plus. Great Grandma's bible images with some transcription on the page, then links to the folks included in it as well as a copy and paste citation-definitely something worth pursuing.