FamilySearch Wiki:WikiProject Integrating Place Standards Database with FamilySearch Wiki
- 1 Introduction
- 2 Issues for which there are proposed solutions
- 2.1 How to merge authorities data with user-submitted page
- 2.2 Merging current place pages with database-generated pages
- 2.3 Making titles readable by both humans and the standards database
- 2.4 Don't create millions of stubs
- 2.5 Google and the wiki search engine need to see most data in standards database
- 2.6 Extension needs to work with FCK
- 3 Issues to work out
An extension was created that can inject a lot of data about places into place pages on the wiki. "Place authorities" data, which for years has been kept on an LDS Family History Department internal database, would display on wiki pages somewhat like the data in the infobox on Wikipedia's Palo Alto page. The authorities database contains information such as a place's name, its variant names and spellings, latitude and longitude, creation date, parent locality, and child jurisdictions. There is also a field for the time period when the place or jurisdiction was active.
Issues for which there are proposed solutions
After integration, when someone wants to add a place page, how would the extension know that the place the customer is creating a page for equals a certain place in the database? Answer: when someone searches for a place, the extension would find possible matches and let the patron select one. For the system to do that, we'd have to write our own search which basically duplicates the search in an internal app called Standard Finder. The day this was demo'd, this app wasn't working. After a search, we waited 30 seconds without a result. This app also resides on Labs, and that iteration of the app produced results quickly.
Merging current place pages with database-generated pages
When the standards database adds data for a place, how would the data get added to a page that already exists for the place? If place pages are categorized with "place", then a bot could transform all our current pages into a mashup.
Making titles readable by both humans and the standards database
We need to modify the extension and/or the skin to show a human-readable title while hiding the "Place:" and the numerical ID. Using namespace to do this is problemmatical: If we include this new namespace in the title, it confuses customers. If the namespace on the title is not displayed, users will not realize why search isn't finding an article (because it's in a namespace which isn't searched by default.) Our leaning now is to make the title of the page be what's in the "full name" field in the authorities form.
Don't create millions of stubs
We don't want to create all the place pages at once as stubs which only contain the authority database data.
Google and the wiki search engine need to see most data in standards database
Since all the data in the form appends the dbase but not the wiki, Google couldn't find it. We need updates to the authorities database to update the wiki as well.
Extension needs to work with FCK
Test whether the extension which creates an info box is compatible with FCK. FCK breaks templates. The extension uses embedded template, so it might work.
Issues to work out
- When users add data to the fields, no data is added to the wiki. When data is added to the first half of the fields, data is written to the standards database. Additions to the second half of the fields would be submitted.
- Prevent variant names from displaying in the page, or display just the top 5 variants and have a "more" link that leads to the rest.
- We need to decide which fields we want to display on a place page, and which data within each field we want to display. For instance, we might not want to list every cemetery in a county within the infobox, but we might want to list it on the content pane of the page in a box.
- Should we include a boilerplate for the main content pane of a place page which has certain headings about a place? This way when a place page is generated, it doesn't contain only the place authorities data.