<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
   <channel>
      <title>NHGIS - Unfortunates</title>
      <link>http://blog.lib.umn.edu/mpc/unfor/</link>
      <description></description>
      <language>en</language>
      <copyright>Copyright 2009</copyright>
      <lastBuildDate>Tue, 21 Feb 2006 15:04:26 -0600</lastBuildDate>
      <generator>http://www.sixapart.com/movabletype/?v=4.25</generator>
      <docs>http://blogs.law.harvard.edu/tech/rss</docs> 

      
      <item>
	
         <title>Extended Instructions for Ones and Twos</title>
         <description><![CDATA[<p>1. How do I know when "there's only a data dictionary file available to<br />
serve as the source document"?</p>

<p>	A: The source file will have the extension .dct and there wont be any other resources for it.<br />
 <br />
2. Should I always be sure to check the title of a document on the Census<br />
website?<br />
	A. This is not necessary as long as you have the file you are working from, which you will find in the â€œIncomingâ€? box, but, for part two it might be a good idea if you want to check- at least for the sake of the â€œalternative titleâ€? slot.</p>

<p>3. "If your source is an ICPSR codebook, the agency is ICPSR and the ID<br />
number is the study number, which is always printed on the first page of<br />
ICPSR codebooks"<br />
What if its not an ICPSR codebook? do I just erase the IDNo markup? I don't<br />
think I've yet seen an ICPSR codebook... what do they look like?<br />
	A. If your source is from the Library, it is the call number. Other than these tow circumstances, you donâ€™t need to worry about filling in the IDNo slot.</p>

<p>4. What exactly does <rspStmt>  reffer to? <br />
	A: This is who is responsible for the work. In part 1, it will be the MPC. In part 2 it will be the ICPSR or the Bureau of the Census.</p>

<p>5. Is "The year the source documentation was produced," the year that the<br />
information was gathered, or the year that it was put together and/or<br />
released as a cohesive work? (I've been using the latter)<br />
	A. This is the date that the version of the file which we are using was published/put out for people to use. It may be different than the year that the information was gather and deals with. For the Census Bureau files, the month and day of collection and the month and day of production will always be April 1st, xxxx (year).</p>

<p>6. I am very confused about version type. The instructions say "Itâ€™ll<br />
either be a type of release or an edition and ICPSR is always edition." But<br />
I dont know where to find out that information within the files... Oh, and<br />
in the first file I did one and two for, you said to just delete that, so<br />
that's what I've been doing.<br />
	A: ICPSR files will always be an â€œeditionâ€? and Census files will almost always be a â€œrelease.â€? You should be able to find this within the file thatâ€™s in the â€œIncoming.â€? If you canâ€™t, itâ€™s not a big deal.</p>

<p>7. I'm not *entirely* clear on the difference between "Citation for the<br />
source documentation, not the source study" I think I've done alright on<br />
this so far, but I think I found the seperate files mostly by luck... How<br />
much difference is there usually between these two?<br />
	A: Usually there isnâ€™t much difference if any between the two.</p>

<p>8. What would "multiple source documents" consist of, and how would I know?<br />
Would I have been working out of all of them? (Hasn't been a problem...)<br />
	A: Unfortunate LocMap makers will not be dealing with any multi-source files. It might happen in the future, but you will then need to ask Amy W. for her help with citing them.</p>

<p>9. Where would I usually find the abstracts for the various files? Do I<br />
paste in the entire thing?<br />
	A: The abstract for the file can be found on either the Census website, the ICPSR website, or the Incoming file box, or, if it is from a library material, you may find it on the University library catalog site, in the description of the book/cd/etc. It is not important which abstract you use so long as it adequately explains what the data contained in the study is about. However, we would like this to be kapt succinct, and the abstract off of the Census website tend to run a page or so long, so you might want to either cut them or use a different abstract.</p>

<p>12. â€œcollDateâ€? versus â€œtimeperiodâ€?? (Does the April first rule always aply?)<br />
	A: The collection date is the collection date, and timeperiod means the production time. Once again, collection date will always be April 1st because the Census does all the actual data collection. The date and year depend on whoâ€™s file weâ€™re using- whether it was produced by ICPSR or produced by the Census. (If it was produced byt the Census, once again it will be an April 1st file.)</p>

<p>13.geogCover, geogUnit, universe, are all things that I'm not seeing in<br />
your instructions. So far, I've grasped the cover pretty well (USA), and figure<br />
out the unit after a bit of searching, but, sorry to have to ask an obvious sounding question, but what is my universe? (Winter break has erased odd things from my mind...)<br />
	A: If you canâ€™t find this on the â€œIncomingâ€? file, you will find it on the Census or ICPSR websiteâ€™s version of the file. This is an important element to make sure you get right.</p>

<p>14. dataCollector would just be the census or the ICPSR again, right?<br />
	A: The data collector will always always be the Bureau of the Census.</p>

<p>15. <resInstru></resInstru>  Whats this?<br />
	A: We donâ€™t know. We leave it blank.</p>

<p>16. <citReq></citReq> Whats this? (Its under "use statement..."<br />
	A: This is just the same old document Citation again.</p>]]></description>
         <link>http://blog.lib.umn.edu/mpc/unfor/2006/02/extended_instructions_for_ones.html</link>
         <guid>http://blog.lib.umn.edu/mpc/unfor/2006/02/extended_instructions_for_ones.html</guid>
         <category></category>
         <pubDate>Tue, 21 Feb 2006 15:04:26 -0600</pubDate>
      </item>
      
      <item>
	
         <title>Configuring TextPad to Make it Easier to Use</title>
         <description><![CDATA[<p>Some TextPad Modifications that might come in handy:</p>

<p>You can set your own shortcuts for commands as follows:<br />
From the Configure menu, choose Preferences. The Preferences dialog box is displayed. <br />
Select the Keyboard page. <br />
Select the command category from the list, and the corresponding commands in that category will be displayed. <br />
Select the command you wish to set a shortcut for. <br />
Type the shortcut in the "Press new shortcut key" box. It may consist of one or two characters. <br />
Click the Assign button. </p>

<p>Example: change the current Find command of F5 to "CTRL+F" like in Internet Explorer</p>

<p>You can customize these view settings by choosing Preferences from the Configure menu:</p>

<p>Line numbers Display line numbers in the left margin of each view. This option changes the default for all documents. Use the command on the View menu to change it for the active document only. </p>

<p>Tabbed document selector Control whether it is displayed at the top or bottom of the window, and whether it is stacked or scrolling. Use the command on the View menu to display or hide the tabs. </p>

<p>Add the xml.syn and dditags.tcl to TextPad:</p>

<p>Get them from aggdata\METADATA\WORKING\Instructions and save them to the "[user profile]\Application Data\TextPad" folder</p>]]></description>
         <link>http://blog.lib.umn.edu/mpc/unfor/2006/01/configuring_textpad_to_make_it.html</link>
         <guid>http://blog.lib.umn.edu/mpc/unfor/2006/01/configuring_textpad_to_make_it.html</guid>
         <category></category>
         <pubDate>Fri, 06 Jan 2006 17:06:54 -0600</pubDate>
      </item>
      
      <item>
	<enclosure url="http://blog.lib.umn.edu/mpc/unfor/images/howtouse.gif" length="71574" type="image/gif" /><enclosure url="http://blog.lib.umn.edu/mpc/unfor/images/putty.gif" length="20227" type="image/gif" /><enclosure url="http://blog.lib.umn.edu/mpc/unfor/images/recgroup.gif" length="7078" type="image/gif" />
         <title>LocMaps for SSF files</title>
         <description><![CDATA[<p>When you make locMaps for SSTF files, there are four parts to the process.  <br />
You will map:<br />
A. the variables not in nCubes at the beginning of each line<br />
B. the line numbers at the end of each line<br />
C. the nCubes<br />
D. the filler spaces after the nCubes</p>

<p><br />
You will need:<br />
1. aggdata\\INCOMING\1990-SSF\whichever one you're working on\Docs\HOWTOUSE.ASC (if more than one, use all)*<br />
2. aggdata\\INCOMING\1990-SSF\whichever one you're working on\Docs\IDEN_FTN.ASC (if more than one, use all)**<br />
3. aggdata\\INCOMING\1990-SSF\whichever one you're working on\Docs\TBL_OUT.ASC (if more than one, use all)<br />
4. putty.exe (download from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)<br />
5. aggdata\Programs\LocMap_normal_var.pl (copy from here to the directory where your file is)<br />
6. aggdata\Programs\LocMap_nCube_3.pl (copy from here to the directory where your file is)<br />
7. TextPad<br />
8. an extra file for storing the locMap parts<br />
9. the xml file for which the locMap is being created<br />
10. an unzipped copy of the data file in stored in aggdata\TRANSLATED\1990-SSF available for viewing.</p>

<p><br />
*IDEN_FTN.ASC has the record layout (with file widths, etc) for the geographic and other non-nCube variables (denoted with an "M" for misc.). <br />
**HOWTOUSE.ASC has the record layout for the nCubes.</p>

<p><br />
I. Print or have open for viewing 1 and 2.</p>

<p><br />
II. Start putty following the instructions below:<br />
<img alt="putty.gif" src="http://blog.lib.umn.edu/mpc/unfor/images/putty.gif" width="455" height="440" /><br />
You'll get a black screen asking you to log in.  Use your mpc username and password.  Then navigate to the directory where the files and programs are with this command:<br />
cd /pkg/aggdata/METADATA/dropbox/amy<br />
If you are not working in dropbox, change as appropriate.  </p>

<p><br />
III. As needed, use these UNIX commands:<br />
a1. ls = show me everything in my directory<br />
a2. hitting the up arrow will enter in text you've entered so far in your session.  So, if you've run a locMap program once, you don't have to type it again.  Just hit the up arrow.<br />
a3. Paste copied text by hitting the right mouse button.  Inside putty, highlighting text also copies it.<br />
a4. You can use the Tab key to fill out the rest of a directory name if that directory name is unique.  Soooo..."cd /pkg/agg" + the Tab key fills out the rest of aggdata.  It only takes one capital M to get metadata and one lower case d to get dropbox.</p>

<p><br />
IV. Map the variables not in nCubes at the beginning of each line<br />
Start LocMap_normal_var_v2.pl (see below). <br />
<b>Bold</b> text = prompts from the LocMap_normal_var_v2.pl program; the rest are examples of what you would enter.</p>

<p>./LocMap_normal_var.pl<br />
<b>Enter file name:</b> STF3-1-2-3-4.xml<br />
<b>Enter the variable ID of the first and last variable of your range (ex:U18-U20):</b> ***<br />
Mb>Input the number of repetitions for record identification strings that occur on EACH physical part of a longer logical record:</b> 0 (or 1 or 16 or whatever) ****<br />
<b>Input the start position for first dataItem:</b> 1 (always)<br />
<b>Input Variable widths:</b><br />
<b>Variable ID U18:</b> 3 (these numbers come from IDEN_FTN.ASC)<br />
<b>Variable ID U19:</b> 6<br />
<b>Variable ID U20:</b> 2<br />
<b>Would you like to add any FILLS in this range(y/n):</b> n (always n)</p>

<p>***Do not include the FILL or LINENO (LINENO= line number) variables in this group.</p>

<p>****The number of repetitions refers to record segments which are listed in the HOWTOUSE.ASC file.  Open the file and do a find for "Segmentation of SSTF{fill in the number} Records".  Count the TOTAL number of segments (whether a, b, c or whatever) and that's what you enter here.  So a file with 1 A segment and 12 B segments has 13 total and you should enter 13.  The image below shows the start of a segment listing (ignore the green text/arrows for now):</p>

<p><img alt="howtouse.gif" src="http://blog.lib.umn.edu/mpc/unfor/images/howtouse.gif" width="600" height="482" /></p>

<p>When you finish, an output file of the pattern "LocMap_normal_var.output" will be created in the same directory.</p>

<p><br />
V. Save contents of LocMap_normal_var output to 7 and save.</p>

<p><br />
VI. Map the line numbers at the end of each line<br />
-Open the data file.<br />
-Hit the End key.<br />
-Look at the bottom of the Textpad window for the character number (see image).<br />
-That's the line length.<br />
-Scroll down to the last line of the file.<br />
-Note the line number (2043 or 77 or whatever).<br />
-Open 7.<br />
-Copy the last dataitem.<br />
-Change the ID to "DI_LINENO"<br />
-Change varRef to "LINENO"<br />
-Change the endPos to the line length (8174 in the image above)<br />
-Change the width to the number of characters of the last line number (4 for 2043, 2 for 77)<br />
-Adjust the startPos accordingly.<br />
-Save this dataitem just above the &lt;/locMap&gt; tag.</p>

<p>Example:<br />
	&lt;dataItem ID="DI_LINENO" source="producer" varRef="LINENO"&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_1" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_2" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_3" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_4" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_5" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_6" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_7" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_8" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_9" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_10" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_11" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_12" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_13" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_14" startPos="8172" width="3" endPos="8174" /&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_15" startPos="8172" width="3" endPos="8174" /&gt;<br />
   &lt;/dataItem&gt;</p>

<p><br />
VI. Map the nCubes<br />
<b>Bold</b> text = prompts from the LocMap_nCube_3.pl program; the rest are examples of what you would enter.<br />
The program goes like this:</p>

<p>./LocMap_nCube_3.pl<br />
<b>Enter file name:</b><br />
<b>Enter the ID of the first and last nCube of your range (ex: NPB010-NPB015)</b><br />
<b>Enter recRef:</b><br />
<b>Enter Start position:</b><br />
<b>Enter width:</b></p>

<p>The program ends and an output file is created.</p>

<p>Now, SSTF files are broken into segments.  These segments often start and/or end in the middle of an nCube.  The program above can't capture this kind of break - it can only work with a whole table at a time.  This means you have to construct the locMap segment by segment using the HOWTOUSE.ASC file.  </p>

<p>Because the geography variables should all end at position 300, then each record segment (which is equal to 1 or more lines in the data file) should start at 301.  In other words, multiple data items reference the same space.  This is ok because each data item references a different record group, so each item is still a unique combination of record group and position.  </p>

<p>If each segment broke at the end of each table, then you would run the LocMap_nCube_3.pl program once for each record segment.  Instead, as you can see below, segments begin and/or end in the middle of tables.  </p>

<p><img alt="howtouse.gif" src="http://blog.lib.umn.edu/mpc/unfor/images/howtouse.gif" width="600" height="482" /></p>

<p>Or, to put it this way:</p>

<p><img alt="recgroup.gif" src="http://blog.lib.umn.edu/mpc/unfor/images/recgroup.gif" width="600" height="27" /></p>

<p>LocMap_nCube_3.pl doesn't account for these kinds of breaks.  Therefore, not only do you have to run the LocMap_nCube_3.pl program once for each record segment, but you have to adjust your starting position for each segment so that the whatever data item is at position 301 is the one you are supposed to start with.</p>

<p>For example, based on the image above:</p>

<p>The input for record A (REC_1) would be:<br />
range: NPA001-NHA003<br />
record ID:  REC_1<br />
start position: 301<br />
width: 9</p>

<p>The input for record B segment 1 (REC_2) would be:<br />
range: NPB001-NPB007<br />
record ID:  REC_2<br />
start position: 301<br />
width: 9 </p>

<p><b>NOTE:</b> ALL dataItems starting with the 32nd data item in table NPB007 will be deleted as they are NOT in this segment.</p>

<p>The input for record B segment 1 (REC_3) would be:<br />
range: NPB007-NPB018<br />
record ID:  REC_3<br />
start position: 22<br />
width: 9</p>

<p><b>NOTE:</b> All dataItems BEFORE NPB007 cell 32 will be deleted (cell 32 should have a start position of 301). All dataItems starting with the 73rd dataItem in table NPB018 will be deleted as they are NOT in this segment.</p>

<p>The input for Record B segment 3 would be:<br />
range: NPB018-NPB022<br />
record ID: REC_4<br />
start position: 301 - (72*9) = -347<br />
width: 9</p>

<p><b>NOTE:</b> Same type of editing as before. Note that dataItem 73 in NPB18 starts in position 301. Because there are more than 300 characters in 72 cells (648) the start location you enter has to be a negative number to get the first cell of this table located in this segment to start at 301.  All dataItems starting with the 134th dataItem in table NPB022 will be deleted as they are NOT in this segment.</p>

<p>You repeat this process until you reach the end of the record segments.  </p>

<p><br />
VII. Map the filler.<br />
On each line, after the nCube data, but before the line numbers will be some blank spaces.  We account for these using the FILL variable.<br />
-After creating each locMap segment in VI, go to the last dataitem.<br />
-Copy this:</p>

<p>	&lt;dataItem ID="DI_FILL#" source="producer" varRef="FILL"&gt;<br />
	  &lt;physLoc source="producer" recRef="REC_#" startPos="#" width="#" endPos="#" /&gt;<br />
   &lt;/dataItem&gt;</p>

<p>-Each fill is sequential starting with 1.  <br />
-The REC_# should match the one it's filling out.<br />
-The startPos = (endPos of preceding dataitem + 1)<br />
-The endPos = (startPos of the lineno dataitem - 1)<br />
-The width is the difference</p>

<p><br />
VIII. Map "FILLER Tables" as filler variables.<br />
In some cases, a record segment ends in the middle of a "FILLER Table".  That means that the next segment begins with a FILLER Table and you need to calculate the correct start and end positions for the FILL variable that replaces the table and the first nCube in that segment.</p>

<p>Say you have two segments like this:</p>

<pre>
Segment 9

<p>Geographic Identification      PB40--17 data cells--through<br />
  Information                  PB44--259 data cells<br />
                               <br />
                               8,165 characters including<br />
                               5 characters filler</p>

<p>Segment 10</p>

<p>Geographic Identification      PB44--227 data cells--through<br />
  Information                  PB45--388 data cells<br />
                               <br />
                               8,165 characters including<br />
                               2 characters filler<br />
</pre></p>

<p>Check in TBL_OUT.ASC to see if either of the tables at the beginning or end is a FILLER Table.  It will look like this:</p>

<p>PB47. FILLER</p>

<p>In those cases, before re-running LocMap_nCube_3.pl, insert another blank FILL variable.</p>

<p>-The REC_# should match the one it's filling out.<br />
-The startPos = 301<br />
-The endPos = 301+(the number of data cells for that table x 9) (in the example above, it would be 301+(227x9) = 2344<br />
-The width is the difference</p>

<p>When you run LocMap_nCube_3.pl now,  your nCube range is just PB45 and the startPos is 2344+1.<br />
Then clip off the extra dataitems as in V.</p>

<p>IX.<br />
When you have finished, copy the contents of your holding file (e.g. the whole locMap) into your original xml file immediately above &lt;dataDscr&gt;.  Save and email me that you've finished.</p>]]></description>
         <link>http://blog.lib.umn.edu/mpc/unfor/2006/01/locmaps_for_ssf_files.html</link>
         <guid>http://blog.lib.umn.edu/mpc/unfor/2006/01/locmaps_for_ssf_files.html</guid>
         <category></category>
         <pubDate>Fri, 06 Jan 2006 12:54:40 -0600</pubDate>
      </item>
      
      <item>
	
         <title>Resources for creation sections 1 &amp; 2</title>
         <description><![CDATA[<p>When you're putting in the info in sections 1 & 2 these resources will be handy:</p>

<p>1. The DDI schema - helps in case you get lost in repeating elements: http://webapp.icpsr.umich.edu/cocoon/DDI-STRUCTURE/Version2-1.xsd</p>

<p>2. The ICPSR Study description (if your file has one): http://www.icpsr.umich.edu/<br />
2.1 Enter the ICPSR study number (on the first page of the documentation) and select "Study No" in the search field.<br />
2.2 Wnen you get the results, click on "Description".</p>

<p>3. The full documentation file which will be in aggdata/INCOMING/xxxxx  If you don't see anything that looks like your file, try looking in ICPSR-Studies in INCOMING.</p>

<p>4. To find the other people who've done data entry on the files, go to aggdata/METADATA/WORKING/amy/Excel/Amy_tracking.xls; list everyone associated...</p>

<p>Sandy and Amy K (although she's gone now till Spring Semester starts) have walked through this and can help...</p>]]></description>
         <link>http://blog.lib.umn.edu/mpc/unfor/2005/12/resources_for_creation_section.html</link>
         <guid>http://blog.lib.umn.edu/mpc/unfor/2005/12/resources_for_creation_section.html</guid>
         <category></category>
         <pubDate>Fri, 16 Dec 2005 15:57:57 -0600</pubDate>
      </item>
      
      <item>
	
         <title>If you need Amy M-Th...</title>
         <description><![CDATA[<p>If you need to ask me something on a day other than Friday, feel free to email or come to the library.  You can see if I'll be available by going to <a href="https://umcal.umn.edu/global-bin/ocas.fcgi?sub=web&web=gbl&viw=%a0%bd%aa%ae%a3%ec%e9%eb&xen=%e1%ef%e1%f5%ef%ec%ed">my public schedule</a>.</p>]]></description>
         <link>http://blog.lib.umn.edu/mpc/unfor/2005/12/if_you_need_amy_mth.html</link>
         <guid>http://blog.lib.umn.edu/mpc/unfor/2005/12/if_you_need_amy_mth.html</guid>
         <category></category>
         <pubDate>Fri, 16 Dec 2005 15:57:29 -0600</pubDate>
      </item>
      
      <item>
	
         <title>Valid/Invalid Ranges for Geo Vars</title>
         <description><![CDATA[<p>In the case when a geo var has a range (eg 01-52, 98, 99) of possible catValus we should use a "valid/invalid range." For instance, in the 2000 SF1 the variable "Congressional District 110"  is listed in  the data dictionairy. For this variable, the values 01-52 correspond to "The Actual congressional district number",value 00 "Applies to states whose representative is elected â€˜â€˜at largeâ€™â€™; i.e., the state has only one representative in the United States House of Representatives" and so on. </p>

<p><br />
&lt;var ID=&quot;G52&quot; name=&quot;CD110&quot;&gt;<br />
&lt;location locMap=&quot;LM&quot;/&gt;<br />
&lt;labl level=&quot;var&quot;&gt;Congressional District (110th)&lt;/labl&gt;<br />
&lt;valrng&gt;<br />
&lt;range min=&quot;00&quot; max=&quot;52&quot;/&gt;<br />
&lt;range min=&quot;98&quot; max=&quot;99&quot;/&gt;<br />
&lt;key&gt;01-52: The Actual congressional district number; 00: Applies to states whose representative is elected â€˜â€˜at largeâ€™â€™; i.e., the state has only one representative in the United States House of Representatives; 98: Applies to areas that have an â€˜â€˜at largeâ€™â€™ nonvoting delegate or resident commissioner in the United States House of Representatives; 99: Applies to areas that have no representation in the United States House of Representatives&lt;/key&gt;<br />
&lt;/valrng&gt;<br />
&lt;/var&gt;</p>

<p></p>

<p>We should use valid/invalid range when the codes we are referencing aren't commonly known. A couple examples of commonly known schemes  are FIPS or MCD. It's not always so easy to know when coding schemes are "commonly known" so if there is any question ask either Wendy or Amy. </p>]]></description>
         <link>http://blog.lib.umn.edu/mpc/unfor/2005/12/validinvalid_ranges_for_geo_va_1.html</link>
         <guid>http://blog.lib.umn.edu/mpc/unfor/2005/12/validinvalid_ranges_for_geo_va_1.html</guid>
         <category></category>
         <pubDate>Fri, 09 Dec 2005 13:41:03 -0600</pubDate>
      </item>
      
      <item>
	
         <title>Blog&apos;s Nearly Back</title>
         <description><![CDATA[<p>So, our blog disappeared a while back.  I did recover the old entries and they should be getting imported any day now.  In the meantime, this one's ready to start using for new entries.  You'll note that Jeff has already added an entry.</p>

<p>The address is http://blog.lib.umn.edu/mpc/unfor</p>

<p>Everyone receiving this message can add entries to the blog except Wendy because she has previously indicated that she doesn't want to :)  You would go to the address above, click on Login and enter your regular UofM username and password.</p>

<p>If you add something you want to be sure everyone sees or that is time-sensitive, after you save the entry, the screen will reload and in the light blue bar at the top is a link for notification.  Click that and choose whether you want to send part of the entry, all of it or none of it and submit.  An email will be sent to all unfortunates, Jennifer, Wendy and me.</p>

<p>If you are new to blogs, let me know and I'll give you a quick introduction!</p>]]></description>
         <link>http://blog.lib.umn.edu/mpc/unfor/2005/12/blogs_nearly_back.html</link>
         <guid>http://blog.lib.umn.edu/mpc/unfor/2005/12/blogs_nearly_back.html</guid>
         <category></category>
         <pubDate>Fri, 02 Dec 2005 11:01:41 -0600</pubDate>
      </item>
      
      <item>
	
         <title>Nesting catgryGrps - use &quot;catGrp&quot;</title>
         <description><![CDATA[<p>catgryGrps can be nested inside each other! It's neat! You do this by listing another catgryGrp as one of the component parts of the catgryGrp that includes it.</p>

<p>However, I've noticed a mistake that's in a few older files . . . I don't know how pervasive it is. </p>

<p>This is the mistake:<br />
&lt;catgryGrp ID="CVG1_1" catgryGrp="CVG1_2 CVG1_3" catgry="CV1_5 CV1_6 CV1_7"&gt;</p>

<p>This is how it should look:<br />
&lt;catgryGrp ID="CVG1_1" catGrp="CVG1_2 CVG1_3" catgry="CV1_5 CV1_6 CV1_7"&gt;</p>

<p>The subtle nuance is that you need to use "catGrp", not "catgryGrp"</p>]]></description>
         <link>http://blog.lib.umn.edu/mpc/unfor/2005/12/nesting_catgrygrps_use_catgrp_1.html</link>
         <guid>http://blog.lib.umn.edu/mpc/unfor/2005/12/nesting_catgrygrps_use_catgrp_1.html</guid>
         <category></category>
         <pubDate>Fri, 02 Dec 2005 10:16:46 -0600</pubDate>
      </item>
      
   </channel>
</rss>
