FamilySearch Wiki:WikiProject Integrating Place Standards Database with FamilySearch WikiEdit This Page

From FamilySearch Wiki

(Difference between revisions)
(New page: == Introduction == An extension was created that can inject a lot of data about places into place pages on the wiki. *Authority data would display something like the data in the infobo...)
 
m (inactive template)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{WikiProject status|Inactive}}
 
== Introduction  ==
 
== Introduction  ==
  
An extension was created that can inject a lot of data about places into place pages on the wiki.  
+
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 [http://en.wikipedia.org/wiki/Palo_Alto 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. <br>  
 
+
*Authority data would display something like the data in the infobox on [http://en.wikipedia.org/wiki/Palo_Alto Wikipedia's Palo Alto page].<br>
+
  
 
== Issues for which there are proposed solutions  ==
 
== Issues for which there are proposed solutions  ==
  
=== How to merge authorities data with user-submitted page<br> ===
+
=== How to merge authorities data with user-submitted page ===
  
 
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.  
 
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 ===
+
=== 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.<br>
+
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.<br>  
  
=== Making titles readable by both humans and the standards database ===
+
=== 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.)  
+
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.<br>
  
=== Don't create millions of stubs<br> ===
+
=== 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.<br>
+
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  ==
 
== 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 <br>
+
#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.
#What's the human-readable part of the title for Jefferson County<br>
+
#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.
 +
 
 +
== External links  ==
 +
 
 +
*The [https://labs.familysearch.org/stdfinder/PlaceStandardLookup.jsp Standards Finder] on FamilySearch Labs shows the current hierarchy for place authorities that need to be adopted into the Wiki through the categories.
  
<br>
+
[[Category:WikiProjects]]

Latest revision as of 22:44, 17 January 2013

Contents

Introduction

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

How to merge authorities data with user-submitted page

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

External links

  • The Standards Finder on FamilySearch Labs shows the current hierarchy for place authorities that need to be adopted into the Wiki through the categories.
  • This page was last modified on 17 January 2013, at 22:44.
  • This page has been accessed 973 times.