admin/install/LibData_Intro.rtf

{\rtf1\ansi\ansicpg1252\uc1 \deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}{\f2\fmodern\fcharset0\fprq1{\*\panose 02070309020205020404}Courier New;}
{\f16\froman\fcharset238\fprq2 Times New Roman CE;}{\f17\froman\fcharset204\fprq2 Times New Roman Cyr;}{\f19\froman\fcharset161\fprq2 Times New Roman Greek;}{\f20\froman\fcharset162\fprq2 Times New Roman Tur;}
{\f21\froman\fcharset186\fprq2 Times New Roman Baltic;}{\f28\fmodern\fcharset238\fprq1 Courier New CE;}{\f29\fmodern\fcharset204\fprq1 Courier New Cyr;}{\f31\fmodern\fcharset161\fprq1 Courier New Greek;}{\f32\fmodern\fcharset162\fprq1 Courier New Tur;}
{\f33\fmodern\fcharset186\fprq1 Courier New Baltic;}}{\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue255;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red255\green255\blue0;\red255\green255\blue255;
\red0\green0\blue128;\red0\green128\blue128;\red0\green128\blue0;\red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red128\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adjustright \fs20\cgrid \snext0 Normal;}{
\s1\qc\keepn\widctlpar\outlinelevel0\adjustright \fs28\cgrid \sbasedon0 \snext0 heading 1;}{\s2\keepn\widctlpar\outlinelevel1\adjustright \b\fs28\cgrid \sbasedon0 \snext0 heading 2;}{\s3\keepn\widctlpar\outlinelevel2\adjustright \b\cgrid 
\sbasedon0 \snext0 heading 3;}{\*\cs10 \additive Default Paragraph Font;}{\*\cs15 \additive \ul\cf2 \sbasedon10 Hyperlink;}{\s16\widctlpar\adjustright \cgrid \sbasedon0 \snext16 Body Text;}{\s17\widctlpar\adjustright \fs20 \snext17 HTML Body;}{
\s18\widctlpar\adjustright \f2\fs20 \snext18 HTML Pre-tag;}{\*\cs19 \additive \ul\cf12 \sbasedon10 FollowedHyperlink;}}{\*\listtable{\list\listtemplateid1656108364{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0
{\leveltext\'03\'00.0;}{\levelnumbers\'01;}\fbias0 \fi-720\li720\jclisttab\tx720 }{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0{\leveltext\'03\'00.\'01;}{\levelnumbers\'01\'03;}\fbias0 \fi-720\li1440\jclisttab\tx1440 }
{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0{\leveltext\'05\'00.\'01.\'02;}{\levelnumbers\'01\'03\'05;}\fbias0 \fi-720\li2160\jclisttab\tx2160 }{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0
\levelindent0{\leveltext\'07\'00.\'01.\'02.\'03;}{\levelnumbers\'01\'03\'05\'07;}\fbias0 \fi-720\li2880\jclisttab\tx2880 }{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0{\leveltext
\'09\'00.\'01.\'02.\'03.\'04;}{\levelnumbers\'01\'03\'05\'07\'09;}\fbias0 \fi-1080\li3960\jclisttab\tx3960 }{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0{\leveltext\'0b\'00.\'01.\'02.\'03.\'04.\'05;}{\levelnumbers
\'01\'03\'05\'07\'09\'0b;}\fbias0 \fi-1080\li4680\jclisttab\tx4680 }{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0{\leveltext\'0d\'00.\'01.\'02.\'03.\'04.\'05.\'06;}{\levelnumbers\'01\'03\'05\'07\'09\'0b\'0d;}\fbias0 
\fi-1440\li5760\jclisttab\tx5760 }{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0{\leveltext\'0f\'00.\'01.\'02.\'03.\'04.\'05.\'06.\'07;}{\levelnumbers\'01\'03\'05\'07\'09\'0b\'0d\'0f;}\fbias0 \fi-1440\li6480
\jclisttab\tx6480 }{\listlevel\levelnfc0\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0{\leveltext\'11\'00.\'01.\'02.\'03.\'04.\'05.\'06.\'07.\'08;}{\levelnumbers\'01\'03\'05\'07\'09\'0b\'0d\'0f\'11;}\fbias0 \fi-1800\li7560\jclisttab\tx7560 
}{\listname ;}\listid1327199264}{\list\listtemplateid-1136866552\listsimple{\listlevel\levelnfc4\leveljc0\levelfollow0\levelstartat1\levelspace0\levelindent0{\leveltext\'03(\'00);}{\levelnumbers\'02;}\fbias0 \fi-720\li1440\jclisttab\tx1440 }{\listname 
;}\listid2065255344}}{\*\listoverridetable{\listoverride\listid1327199264\listoverridecount0\ls1}{\listoverride\listid2065255344\listoverridecount0\ls2}}{\info{\author DLDL}{\operator DLDL}{\creatim\yr2003\mo10\dy2\hr10\min3}
{\revtim\yr2004\mo3\dy16\hr14\min41}{\version23}{\edmins165}{\nofpages30}{\nofwords11160}{\nofchars-32766}{\*\company University of Minnesota}{\nofcharsws0}{\vern113}}
\widowctrl\ftnbj\aenddoc\hyphcaps0\formshade\viewkind1\viewscale100\pgbrdrhead\pgbrdrfoot \fet0\sectd \linex0\endnhere\sectdefaultcl {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta .}}
{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}
{\pntxta )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl9\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain 
\widctlpar\adjustright \fs20\cgrid {\fs24 File:\tab \tab LibData_Intro.rtf
\par Title:\tab \tab LibData Introduction & Functional Description
\par Author:\tab Paul F. Bramscher brams006@umn.edu
\par Date:\tab \tab March 16, 2004
\par 
\par 
\par }\pard\plain \s2\keepn\widctlpar\outlinelevel1\adjustright \b\fs28\cgrid {Table of Contents
\par }\pard\plain \widctlpar\adjustright \fs20\cgrid {
\par }{\fs24 1.0\tab Introduction
\par 2.0\tab System Accounts
\par 3.0\tab Resources
\par 4.0\tab Subjects
\par 5.0\tab Authoring Environments
\par }\pard \li720\widctlpar\adjustright {\fs24 5.1\tab Research QuickStart (RQS)
\par 5.2\tab PageScribe (PS)
\par 5.3\tab CourseLib (CL)
\par }\pard \widctlpar\adjustright {\fs24 6.0\tab Manager Functions
\par 7.0\tab DBA Tools
\par 8.0\tab Statistics
\par 9.0\tab Patron Interfaces
\par 10.0\tab Conclusion / Credits
\par 11.0\tab LibData Licensing
\par 
\par 
\par }{\b\fs28 1.0\tab Introduction
\par }{\fs24 
\par LibData can drive many sorts of library-related web pages and collections of pages dynamically from a rich web-maintainable database.  It is not properly placed into existing categories of applications such as content management systems, course manag
ement tools, subject pathfinder builders, or catalogs.  It is probably a little of each, with the ability to change emphasis depending on how the data set is populated and used locally.
\par 
\par The system has two main authoring environments: CourseLib/PageScribe 
(referred to collectively as CLPS) and Research QuickStart (RQS).  CourseLib is a modest library-centric course authoring tool, whereas PageScribe is the free-form version (without the course-related data fields).  They are essentially the same applicatio
n
, capable of building two sorts of pages.  Research QuickStart is an authoring environment to build subject-centric web pages.  These pages are more uniform than CLPS generated pages (only resources may be added to RQS pages, although they may also cross-
reference PageScribe pages), and they are added to a customizable two-tier information type ontology.
\par 
\par There are both public and administrative portions of LibData.  Basic use statistics are collected from the public portion.  An internal authentication and multi-level access system based on roles was also developed to support administrative functions.

\par 
\par It 
is driven by an underlying collection of about forty database tables tied together relationally.  Most all of these tables are maintained through web-based forms and are fully customizable for content -- allowing for a rich authoring environment with a gr
eat deal of possibilities.  The majority of data relationships are optional associations, so LibData's flavor fluctuates in proportion to the work done in populating and associating relationships.
\par 
\par A populated enterprise instance of LibData requires collabo
ration between staff with complimentary areas of expertise.  Such staff might include a unix/linux administrator, a programmer familiar with web scripting technologies, a seasoned SQL/database person, as well as a web designer.  Of course we often need to
 wear more than one hat, but LibData will be more reliable and more customizable (as with any technology) given more staff and levels of expertise.
\par 
\par It is hoped that the programming code is simple, even }{\i\fs24 simplistic}{\fs24 , and self-documenting whenever possible.  T
his self-documentation includes comments which accompany the great majority of the functions, as well as copious use of mid-logic commentary.  Writing obfuscated code comes naturally to programmers, so documentation and clarity are unfortunately goals rat
her than starting points.
\par 
\par 
\par }{\b\fs28 2.0\tab System accounts
\par }{\fs24 
\par The following is a very cursory discussion on role-based security within LibData.  Note that the actual functions are not discussed here (refer to }{\b\fs24 5.0 Authoring}{\fs24 , }{\b\fs24 6.0 Manager}{\fs24  }{\b\fs24 Functions}{\fs24  or }{\b\fs24 
7.0 DBA Tools}{\fs24  respectively for functions available to Authors, Managers, and LibData DBA\rquote 
s).  This section is meant to introduce these roles.  There is also capability for Guest and Denied access levels.  Guest accounts are not yet implemented but might, in the future, allow f
or limited read-only access.  Denied access is useful to lock a user out of the system, but retain his/her account for whatever reason (historical, perhaps they\rquote re on a leave of absence, etc.)
\par 
\par }\pard\plain \s3\keepn\widctlpar\outlinelevel2\adjustright \b\cgrid {Session and state handling
\par }\pard\plain \widctlpar\adjustright \fs20\cgrid {
\par }{\fs24 The login URL will depend on your LibData installation.  It may be something of the form }{\field\fldedit{\*\fldinst {\fs24  HYPERLINK https://www.yourlibrary.edu/libdata/login_mysql.phtml }{{\*\datafield 
00d0c9ea79f9bace118c8200aa004ba90b020000001700000036000000680074007400700073003a002f002f007700770077002e0079006f00750072006c006900620072006100720079002e006500640075002f006c006900620064006100740061002f006c006f00670069006e005f006d007900730071006c002e007000
680074006d006c000000e0c9ea79f9bace118c8200aa004ba90b6c000000680074007400700073003a002f002f007700770077002e0079006f00750072006c006900620072006100720079002e006500640075002f006c006900620064006100740061002f006c006f00670069006e005f006d007900730071006c002e0070
00680074006d006c00000000000000000000000000000000000000000000}}}{\fldrslt {\cs15\ul\cf2 https://www.yourlibrary.edu/libdata/login.phtml}}}{\fs24 .  Note that it\rquote s an https (SSL) port.  Note also that the logout option is currently 
only on the Author console (explained further below), this section is common to all roles.  Sessions are tied to IP address, stored both in a client-side cookie as well as in a server maintained session database.  Once logged in, a session lasts for as ma
ny minutes as specified in the first instantiation of the sessionClass object specified in login.phtml.  The default LibData OS release is 7200, or 2 hours.  Activity or inactivity during this span doesn\rquote 
t affect the longevity of the session.  So it\rquote s assum
ed that LibData staff are accessing the administrative portion through office computers in non-public areas.  They may head out to lunch, coffee, or a short meeting and still come back to an authenticated session.  Note that LibData technical staff can ad
just the 7200 setting in login.phtml to anything else (higher or lower) as desired (with a minimum of 2 minutes and a maximum of 12 hours as defined in sessionClass.php).
\par 
\par }\pard\plain \s3\keepn\widctlpar\outlinelevel2\adjustright \b\cgrid {Visible menus
\par }\pard\plain \widctlpar\adjustright \fs20\cgrid {
\par }{\fs24 There are several access levels: Denied, Guest, Author, Manager, and D
BA.  Currently only Author, Manager, and DBA are implemented.  Anyone below Author access currently has no access, and any account (regardless of access level) is denied if it should have no password assigned to it.  Passwords are assigned and maintained 
by Managers and DBA\rquote s.  As standard practice with unix systems, password are encrypted and never displayed.  As a result, Managers can never retrieve a forgotten password -- but they may reset it to something else.
\par 
\par Users of Author access see only the authoring console (console.phtml).  Managers will notice an additional link at the bottom of the main authoring console allowing them to reach Manager Functions (console_manager.phtml).  DBA\rquote s see a third link 
\ldblquote DBA Tools\rdblquote  (console_dba.phtml).
\par 
\par }\pard\plain \s3\keepn\widctlpar\outlinelevel2\adjustright \b\cgrid {Authors
\par 
\par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\fs24 Authors may create new resources and edit any resource.  They may delete only resources they\rquote ve created themselves.
\par 
\par They have the capability to create CLPS pages.  They may edit and delete their own pages (page creators are by default the initial coordinator of t
hat page).  Additionally, they may be assigned (by another Author, Manager, or DBA) to co-maintain a page.  Authors may not edit or delete pages they are not the coordinators or co-maintainers of.  They may assign other maintainers, and even remove themse
lves from coordinator status.  If an Author selects a new page coordinator -- without first assigning him/herself as a co-maintainer -- the Author is locked out of that page and responsibility for maintenance falls on other staff.
\par 
\par Within the RQS authoring environment, Authors may create new subjects from the \ldblquote New or Delete\rdblquote 
 link on the main authoring console, console.phtml.  The currently logged in Author is initially assigned to the newly created subject.  S/he may add other staff 
persons.  Authors may not edit subjects for which they are not assigned.  So, for example, if an author were to remove him/herself as assigned staff, s/he would be unable to get back into that subject.
\par 
\par }\pard\plain \s3\keepn\widctlpar\outlinelevel2\adjustright \b\cgrid {Managers
\par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\fs24 
\par Managers may create and edit/delete all resources (regardless of whether they created them.)
\par 
\par They may edit CLPS pages they\rquote ve created, are coordinators of, or co-maintainers of.  Additionally, they may edit pages created by any staff person defined as a member of a Library Unit for which they are 
listed as Unit Lead.  Staff may (or may not be) assigned to Library Units by Managers on the Manager Functions console.  Not all Managers need be listed as a Unit Lead.  So there is a subtlety with Manager status: one may have varying degrees of manageria
l rights (being a unit lead or not, and a unit lead over which body of employees).
\par 
\par Whether or not a Manager is a unit lead, s/he may access the Manger Functions console and modify virtually all of the system setup tables, including the assigning and re-ass
igning of Unit Leads themselves.  Thus, this level of access requires a collegial trust among managers.  If one manager leaves the organization, another may put him/herself in that position without calling upon a DBA.  Managers can make sweeping changes t
o the system, potentially destroy it, create user accounts and manage passwords, etc.  Their only limitation on the Manager Functions console is that they may not promote any staff member to an access level higher than Manager itself (DBA).
\par 
\par Newly created s
taff accounts must be assigned a password by a Manager or DBA. The password must be a minimum of 6 characters in length and should contain both alpha and numeric characters.  Interspersing special characters such as !@#$^&() is encouraged for additional s
ecurity (don\rquote t assign passwords containing the single or double-quote characters, since these are problematic from a database perspective).
\par 
\par Managers play a role (as discussed earlier) in assigning Author staff to subjects.
\par So an author\rquote s access to maintain, for example, the Anthropology subject is connected to an association made by a Manager or DBA in one of either two system setup tables.  From the Manager Functions console it\rquote 
s possible to enter the staff maintenance system, select an individual staff pe
rson, and add/remove assigned subjects.  There is also a subject-centric setup table in which staff persons may be added/removed to a particular subject.  In addition to entering one of these setup tables, there is an overall management view under RQS Ass
ignments that displays subjects alphabetically in the left-most column, and assigned staff to each subject in the right-most column.  Entries in either column are clickable, tooling into either the staff or subject maintenance page respectively.
\par 
\par }{\b\fs24 Database Administrators (DBA)
\par }{\fs24 
\par DBA\rquote s may create/update/delete all resources and CLPS pages.  In addition to all functions on the Authoring and Management Functions consoles, they may promote/demote staff to all access levels (including the creation of other DBA\rquote s).
\par 
\par Currently there is little extra that DBA\rquote s can do that Managers cannot \endash 
 although the place for future additional functionality is the DBA Tools screen.  Of particular interest is a CourseLib and PageScribe page debugger, which can analyze pages for possi
ble internal SQL flaws (unlikely, but possible if multiple people do contradictory things to a page at the same time).  We\rquote 
re currently looking at page locking mechanisms and a page fixing tool.  There are also some portal mappings to external (campus-wide) entities that are probably best limited to a DBA role.
\par 
\par In the underlying table structure, each table row typically has a unique ID (primary key) associated with it.  Staff ID#1 is an empty slot, reserved for N/A (with no access rights).  Staff ID#2 is a
lso a special slot, and should be reserved for the System Administrator account.  Beyond this, there is no restriction on the number of accounts or rights assigned to them.
\par 
\par 
\par }{\b\fs28 3.0\tab Resources
\par }{\fs24 
\par Resources will probably be the most common element on  CLPS and RQS pages.  A \ldblquote resource\rdblquote  can be a printed work, an URL, or both simultaneously.
\par 
\par Resources are initially created on the Authoring console b
y entering a title and selecting an initial Master Subject or Master Information Type for it.  (Failing to make an initial selection will result in an explanatory message about what these mean.)  Their purpose is to winnow down the list of Information Typ
e
s in the drop-down box on the Resource entry form.  This list can become large and cumbersome, so both subjects and information types are classified with a two-tier model (roughly analogous to genus/species).  Resources must also have unique titles.  If a
n exact match is found, the resource may not (as currently programmed) be entered.  If a near-hit is found, the system will prompt whether you want to proceed.
\par 
\par The only required field is the resource title.  Assigning a Base Information Type is strongly encouraged, since when that resource is added to RQS pages it\rquote 
ll immediately go to its place in the two-tier information hierarchy.  This may be customized for each instance on Subject pages, but it\rquote s useful to have a likely default location for it.
\par 
\par One the
 resource is saved, additional forms become available: Assign Locations, Features, and Master Subjects.  Data in each of these pick-lists is vocabulary-controlled by a LibData Manager.  Locations (Libraries) should be straightforward.  Features are any fl
agging/tagging characteristics that might be attributed to the resource.  In the Manager Functions menu, Features can be defined with a graphical image or icon (and ALT text) that\rquote ll appear on the public RQS subject page interface.
\par 
\par }\pard\plain \s16\widctlpar\adjustright \cgrid {Resources are searchable with a basic or advanced search (available as a link from the Authoring console).  Their use statistics (see }{\b 8.0 Statistics}{
) are currently being tracked by an exit method implemented on CLPS pages (RQS resource-level usage is not currently tracked, though it may be in a future release).
\par 
\par 
\par }{\b\fs28 4.0\tab Subjects
\par }{
\par LibData Subjects are created by Managers from an option on the Manager Functions table.  They may be associated with a primary and (multiple) secondary locations that appear on that Subject\rquote s corresponding R
QS page.  They may also be created by Authors by clicking \ldblquote New or Delete\rdblquote  on the main console (console.phtml).
\par 
\par They should also be associated with one (or more) Master Subjects.  For example:
\par Social Sciences (Master Subject) -> Anthropology (Subject).
\par 
\par Authors and Managers may also add/remove Authoring staff to work on various subjects.  Another interface is the RQS Assignments option from the Manager Functions menu (mentioned previously under }{\b 2.0 System Accounts}{).
\par 
\par Once a subject has been created, the sub
ject can now appear in the RQS subject pick-list on the Author console.  Note that it depends on whether the currently logged-in staff account has access rights to the subject in terms of whether or not it appears in the list (see the discussion under }{
\b 2.0 System Accounts}{).  DBA\rquote s, for example, will see all subjects in the pick-list, Authors the least.
\par 
\par Note that while a subject appears in the pick-lists for assigned staff it does not yet appear on any public interfaces (it is in an unpublished and empty state).  A subject may now be authored by RQS (refer to}{\b  5.1 Authoring Research QuickStart}{
) below.
\par 
\par In summary, for a subject to be editable, it must either (a) be assigned to the currently logged in Author or (b) the currently logged in manager must be unit l
ead to which the author belongs or (c) all subjects are available if the current user is a DBA.  Alternatively, any manager may simply go in and assign him/herself rights to maintain that subject directly.
\par 
\par 
\par }{\b\fs28 5.0\tab Authoring
\par }{
\par LibData has two main public interfaces: RQS and a page-rendering mechanism that handles CLPS pages.  Both types of authoring are begun from the main authoring console, console.phtml.  New subjects and CLPS pages may be created by Authors by clicking 
\ldblquote New or Delete\rdblquote  below the appropriate pick-list.
\par 
\par When an author clicks to create a new CLPS page, or if the author follows the \ldblquote CourseLib/PageScribe Pages\rdblquote  link in the LibData header, the scribe_start
.phtml page is reached.  From this page, a new CLPS page may be created.  Or the author may select among a list of pages that s/he currently has authorization rights over.  A final option is the ability to Clone & Load any page as a template for a new pag
e.  This command give the author the ability to copy any other author\rquote s work.  A disclaimer prompt is given, to first encourage some sort of agreement with the coordinator of the cloned page.
\par 
\par Both authoring environments will likely pull heavily from the Re
sources table.  Navigating from an authoring environment to create new resources is disrupting to work flow.  Entering a resource suggests one task (cataloging oriented), whereas laying resources out in an authoring environment suggests another (page layo
ut and selection).  Therefore it is recommended that \ldblquote setup\rdblquote 
 tables be populated to the greatest extent beforehand: resources, subjects and master subjects, information types and master information types, locations/libraries, services, staff, etc.  RQS subject or CLPS page design then becomes a much easier task.

\par 
\par The Author menu, also referred to as the authoring console (console.phtml) contains commands to initiate the maintenance of RQS and CLPS pages (and will be detailed in detailed in sections 5.1 and 5.2 below).
\par 
\par Other options on this menu include linking to the statistics screens (specifically treated in }{\b 8.0 Statistics}{), searching for CLPS pages, information demographic drilldowns, a link to a basic or advanced Resource search interface, and the abilit
y to edit or delete resources by a known system ID number.  This number is displayed on all Resource entry/edit forms, as well as on the (administrative side) search results page.
\par 
\par 
\par }{\i Searching CLPS pages
\par }{
\par Note: Due to database structure, instructors are OR\rquote d in the search.  So it\rquote s not possible to permute a search in which you\rquote 
d like to combine a library staff person (as instructor), TA with a faculty person to see which course they were associated with (at most one of the three may be picked).  Other fields
 may be filled in or not to further limit the search.  Most all of the fields are substring-type searches.  For example, entering \ldblquote .gov\rdblquote  (without the quotes) in the URL field will retrieve a list of all .gov URL\rquote 
s on all CLPS pages.
\par 
\par }{\i Drilldowns
\par }{
\par These are available to Authors and above to view demographic relationships of data in LibData.  Note that most of the demographic displays, when fully drilled, have a right-most \ldblquote Edit\rdblquote  command.  Authors may frequently run into a 
\ldblquote not authorized\rdblquote  message when attempt
ing to edit a page or RQS subject over which they have no authority.  Managers may get this message as well, though with less frequency.  So these drilldowns are meant to over an all-encompassing view, not geared toward only the current user\rquote 
s assignments.
\par 
\par 
\par }{\b\fs28 5.1\tab Research QuickStart Authoring
\par }{
\par The editing environment of RQS pages was designed to be as fast as possible at building subject-centric web pages.  We\rquote ve found that work flows best when resources are fully populated into LibData, with as much descrip
tive material as possible.  Of particular utility is to supply a default description and base information type to all resources.  If this is done, much of the work involved in adding them to RQS pages will be minimized since the data will be used as defau
lt settings during its initial placement on RQS pages.
\par 
\par Don\rquote t confuse editing an RQS subject page with editing the subject itself.  Editing the subject will change its description on the public RQS interface, it will also display the subject\rquote s primary locat
ion (library) as well as any secondary location(s).  Modifying these aspects to an RQS page is not handled from the RQS authoring environment (described here).  It is handled from editing the subject record directly, available as an option on both the Aut
hor and the Manager Functions consoles since Location maintains a system-wide controlled vocabulary for its particular data set.
\par 
\par Once an RQS subject has been selected for authoring from the main console, console.phtml, the initial screen the following functionality is available.
\par 
\par }{\b Preview/Publish Commands
\par }{
\par }{\i Preview
\par }{
\par Displays the current RQS subject through the patron interface.  Note that this may involve a switch from SSL to non-SSL, depending on LibData installation.  Browsers may prompt with some sort of notification box.
\par 
\par }{\i Preview Core
\par }{
\par When resources are added to a page they may be added as a \ldblquote core\rdblquote  resource.  On the RQS public interface is a link to \ldblquote show only the core resources.\rdblquote 
  This allows RQS subject authors the ability to create highlighted subsets of the page. Any resource on a page can be switched back and forth from core (see Edit Resources below).
\par 
\par }{\i Publish (or unpublish)
\par }{
\par RQS subject pages are not initially available on the public interface until the RQS page is published.  When published, the \ldblquote Publish\rdblquote  button is replaced with an \ldblquote Unpublish\rdblquote  button.
\par 
\par }{\b Add Resource Commands}{
\par 
\par }{\i Limit
\par }{
\par The resource pick-list can be limited by first letter of the title.  Or it may be limited by a substring search on both the title and description, any \ldblquote features\rdblquote  assigned to it, or by its master information type \endash 
 or any permutation of these limits.  Clicking the \ldblquote Limit\rdblquote  button will limit the pick-list to supplied criteria.
\par 
\par }{\i Add\tab \tab \tab \tab \tab 
\par }{
\par This will add the resource to the RQS page.  Note that the resource automatically goes to its place in the two-tier information hierarchy based on it
s assigned base information type (which hopefully is assigned a master information type).  If either were not given, it goes into the (N/A) category and must be manually moved into a new category (see edit resources below).
\par 
\par Note that there is a subtlety p
rogrammed into the system: it is possible to have the same resource in a particular slot in the information hierarchy on the same page only once.  For example, it is not possible to have Google appear twice on a subject page entitled Internet Literacy und
er the heading WWW Resources -> Web Sites.  However, we\rquote 
ve built an exception case.  Google may be added a second time to the subject page, and this time it will NOT float to its default place on the information hierarchy but, rather, to a (N/A) -> (N/A) po
sition.  It must then be assigned a new information hierarchy position.  Note that assigning it to WWW Resources -> Web Sites when one instance already exists will result in the automatic deletion of the previous instance (enforcing the one time rule of r
esource per RQS page per information type).
\par }\pard \s16\fi720\li2880\widctlpar\adjustright {
\par }\pard \s16\widctlpar\adjustright {Resources may be selected one at a time (no multiple selects implemented yet).
\par 
\par }{\i Add Core
\par }{
\par Identical performance to Add above, except that the resource is added to the resource is added as a \ldblquote core\rdblquote  type resource at the point of addition to the RQS page (and needn\rquote t be toggled as such by editing it later).
\par 
\par }{\b Related RQS Pages
\par }{
\par }{\i Add
\par }{
\par Other RQS may be associated with an RQS page.  This allows additiona
l cross-referencing, they appear on the RQS user-interface, set aside from the main body of resources in an HTML table for display clarity to the user.  RQS pages may be selected multiply.
\par 
\par }{\i Remove
\par }{
\par Removes the selected RQS page(s).  As with Add, multiple selections are possible.}{\b 
\par 
\par Related PageScribe Pages
\par }{
\par }{\i Add
\par }{
\par PageScribe (but not CourseLib pages) may be associated with an RQS page.  This allows additional cross-referencing, they appear on the RQS user-interface, set aside from the main body of resources in 
an HTML table for display clarity to the user.  PageScribe pages may be selected multiply.
\par 
\par }{\i Remove
\par }{
\par Removes the selected PageScribe page(s).  As with Add, multiple selections are possible.
\par 
\par }{\b Edit Resources
\par }{
\par }{\i Edit Base Resource
\par }{
\par This option allows for the editing of the resource itself, which will have system-wide ramifications wherever that resource is used.  A common purpose for using this option would be to fix an outdated URL, correct a typographical error, etc.
\par 
\par 
\par 
\par }{\i Edit This Instance
\par }{
\par Certain characteristics of the resource\rquote s occurrence on this particular RQS page may be tweaked independently of its base/default values, and its occurrence anywhere else in LibData (including on other RQS pages).
\par 
\par }\pard \s16\fi720\widctlpar\adjustright {\i Information Type
\par }\pard \s16\widctlpar\adjustright {The resource may be moved to a different slot in the two-tier information hierarchy.
\par 
\par \tab }{\i Highlighted/Core Resource
\par }{If the resource was originally added as \ldblquote core\rdblquote  or highlighted, it may be unflagged as such \endash  or vice-versa.
\par 
\par \tab }{\i Use Default Description
\par }{This radio button MUST be checked to \ldblquote no\rdblquote  and a unique description supplied in \ldblquote This Description\rdblquote  (see below).  Simply supplying a unique description without explicitly checking \ldblquote no\rdblquote 
 here will result in the changes not going into effect.
\par 
\par Programmer\rquote s Disclaimer: We\rquote 
re looking at making this not required, but the essential problem is that for LibData to determine whether any changes have been made to the default description (thus automatically indicating a custom description) involves comparing data stored in mySQL 
server-side with data that has made the round-trip from server to browser client-side, and back again.  Since we\rquote 
ve allowed for certain characters to be escaped (and potentially more filtering) in the back-end (textInmySQL), and also run through a differen
t parser coming out (textOutHTML), raw character differences will frequently occur.  Thus, in order to make this function reliable, we currently enforce the necessity of manually clicking yes/no to flag this change deliberately, rather than making a poten
tially misleading comparison in the background of data that make differ not to editing changes but for transparent technical reasons.
\par 
\par \tab }{\i This Description
\par }{The default description is the base resource annotation.  It is fully dynamic.  A change to the base resource record will automatically cascade to all occurrences in RQS.  However, if the \ldblquote use default description\rdblquote 
 has been checked to \ldblquote no\rdblquote , a unique description may be supplied here.  This unique description will then not be affected by changes to the base record\rquote 
s annotation at a later date.  It can only be modified by tweaking its occurrence on the RQS page where a unique description was supplied.  Note that the title and URL are always dynamically pulled from the base resource record.
\par 
\par }{\i Remove
\par }{
\par Simply removes this instance of the resource from this RQS page.
\par 
\par 
\par 
\par }{\b\fs28 5.2\tab PageScribe Authoring
\par }{
\par This section covers both PageScribe and CourseLib, since PageScribe is fully a subset of CourseLib.  However there are additional fields and other things to be concerned about with CourseLib.  So all of the commentary (plus additional issues detailed }{
\b in 5.3 CourseLib Authoring}{) apply also to CourseLib.  There is, however, one exception.  PageScribe pages have an additional field, entitled \ldblquote Page Header\rdblquote  which may be populated wit
h HTML source, descriptive text, etc.  CourseLib pages have their own descriptive fields.
\par 
\par General Notes on Page Structure:
\par PageScribe and CourseLib pag
es are built around an outline model with inherent parent-child relationships.  Pages are built with elements.  An element may be of several types (a resource, library/location, a library service, a staffperson, a generic text label,  (up to 64K descripti
on with imbedded HTML, and wrapped with an optional URL), or a link to an RQS page.  RQS pages may also be \ldblquote harvested\rdblquote 
 such that all of their elements are copied to the page (in alphabetical order).  RQS information type hierarchies are not copied with this harvesting procedure, since they don\rquote 
t apply here.  And, as such, the only meaningful way to harvest them is alphabetically \endash  though they may then be moved around with the up/down arrows.
\par 
\par Many of the commands detailed in this section operate on the paren
t-child relationship of page elements.  Deleting a parent allows the possibility of promoting all immediate children to the place of parent, or a cascade delete in which all children and descendents (if any) are likewise deleted.  Similar rules apply with
 copying.  Note that it\rquote s never possible to assign a child to a new parent through adding a new element.  Thus, new page elements may be added only in legal positions: as siblings, new offspring, or before or after entire lineages.
\par 
\par }{\b A word of WARNING:}{
\par We\rquote ve currently NOT implemented locking or concurrency checking.  So it\rquote 
s possible to damage a page if two authors simultaneously perform contradictory structural edits to it.  Thus, it is best to distribute page duties such that there is no overlap.  A page ma
y be checked for integrity through an option available on the DBA Tools console (see }{\b 7.0 DBA Tools}{).  If an error is found, one of three fix methodologies is available to the DBA.
\par 
\par A broken page is best handled by avoidance.  If it is broken, probably the 
best recourse is to print it out, delete it, and ask everyone who might have copied portions of the broken page to purge their copy buffers, and then recreate the page from scratch.  A less damaging option, though perhaps not always successful, is to dele
te only the damaged portion of a page (deleting, copy buffers, etc. will be explained below).  But note, carefully, that copying a damaged parent-child cluster of page elements will potentially \ldblquote replicate\rdblquote  the damaged \ldblquote gene.
\rdblquote   If a SQL guru is available and the page is crucial, damage may be fixed in the mySQL client with some surgically precise analysis on the libdata.elements table.  But be VERY careful with such a procedure...
\par 
\par Programmer\rquote s Note:
\par From the Author console, there is a \ldblquote New or Delete\rdblquote  button 
under both the PageScribe and CourseLib pick-lists.  Both buttons bring the Author to scribe_start.phtml, but depending on which button is selected, the radio button in scribe_start.phtml indicating whether the page is to be a PageScribe page or a CourseL
i
b page is pre-selected.  It may be toggled to the other selection at this point if desired.  If the user has reached this page directly, for example from a link in the LibData authoring header, then PageScribe is the default selection for the new page (an
d
 it may be toggled here).  Once a CLPS page type has been selected, a name chosen, than the authoring environment is entered it may not be switched from PageScribe to CourseLib or vice-versa.  However, portions of the page may be copied and pasted from on
e page type to the other.
\par 
\par A title must be supplied, and uniqueness is not enforced.  Alternately, it is possible load an existing PageScribe or CourseLib page for editing.  As with the Author console, options in both pick-lists are affected by which pages 
the currently logged in user has authority to edit.
\par 
\par So whether a page is newly created or loaded for editing (or deleting) purposes, we\rquote ll now briefly detail the available authoring options.
\par 
\par }{\b Overall Page Commands
\par }{
\par }{\i Create Clone
\par }{
\par The current page may be copied en masse.  What happens in the background is that all page elements and structure are copied to a new page ID.  The page title is prefixed with \ldblquote Copy of:\rdblquote 
 followed by the original source page title.  Note that cloning does not copy over page coordinat
ors and co-maintainers.  These must be re-assigned for the new page (see procedures explained below).  One limitation with our current implementation of cloning is that authors may only clone pages over which they have edit capability (the cloning feature
 is on the page itself).
\par 
\par }{\i Delete Page
\par }{
\par Deletes the currently loaded page.  Authors are prompted with a \ldblquote confirm\rdblquote  box asking whether they really want to do this.  If the page is cross-referenced to any RQS pages, it will be removed from that association as w
ell.  Its statistics will also be purged from the libstats database.  So be careful to archive historical statistics before deleting a page if desired before deleting it.
\par 
\par }{\i Publish/Unpublish
\par 
\par }{The unpublish option becomes available when a page is published and vice-versa.  Note that CourseLib pages have an additional requirement: they may not be published unless a Course subject/designator is selected.  We\rquote 
ve made this a required field for publishing, not so during authoring.
\par }{\i 
\par }{Publishing currently makes the most sense for CourseLib pages, which have a corresponding pick-list interface.  Unpublished CourseLib pages won\rquote 
t appear on the CourseLib user interface.  We currently have not implemented a similar pick-list for PageScribe 
pages, since they are used for a great variety of purposes and share nothing in common with one another (other than the tool they were created with).  However, publishing or unpublishing a PageScribe page, as with CourseLib, has the identical effect of to
ggling the libdata.published flag to true or false (1 or 0).  So a programmer wishing to create a pick-list of PageScribe pages may key off of this field to display or suppress them from a public user interface as we\rquote 
ve done with the CourseLib pick-list.
\par 
\par Programmer\rquote 
s Note: One additional effect of publishing is currently commented out in the scribe_application.php scribePublish() function.  LibData ordinarily displays a dynamic rendition of the page to the user every time the page is loaded.  With the comme
nted out section of code, there is the capability to open a socket to the dynamic page URL itself, suck down all HTML in 4K blocks and build a static snapshot of the page at the instant of publishing.  This snapshot is still stored in a mySQL database fie
ld (64K text type field), but the query to render it is trivial (see publish.phtml in the public interface directory of LibData) both technically and in terms of system utilization.  We\rquote 
ve not yet found a necessity in doing so, so this option has been currently commented out.  Note that we\rquote ve made some changes since we\rquote 
ve tested this functionality, so minor tweaking might be required to get it going again.  But the possibilities are rather interesting.  It would be possible, for example, to build additional 
functionality so that several page snapshots might be available.  We\rquote 
ve had neither the time nor necessity to explore this further, but the functionality is intriguing.  Commented-out code in the scribe.phtml engine allows for the republishing of a page.  
That is, the static snapshot may be refreshed.  All of this was fully functional in previous prototypes but it is currently commented out.
\par 
\par }{\i Preview
\par }{
\par This option previews the currently loaded page in the user interface.  Note that it may involve a switch fr
om an SSL to non-SSL port (as with previewing RQS pages).  An annoying browser message may be involved.  Also, since LibData must constantly refresh the currently loaded page after each command, we must destroy browser cache \endash 
 otherwise the author might be trying to do something on outdated cached page data (which will likely break the page or cause other errors).  So if there is a message about browser cache lost, the page must be reloaded.  We\rquote 
ve found that the Mozilla browser seems to give less annoying expired cache messages than Internet Explorer.
\par 
\par }{\i Show URL\rquote s in Author Mode / Suppress URL\rquote s
\par }{
\par It may be useful for some authors to see URL\rquote s displayed while they are building a page.  This is useful for spot-checking, and gives an idea of what the page may appear like in print-friendly mode (which will display URL\rquote 
s).  Note that this setting has no effect on the user interface, only on the authoring environment for this particular page.  The suppress option becomes available if URL\rquote s are currently display and vice-versa.
\par 
\par }{\i Suppress TOC / Activate TOC
\par }{
\par Pages can have an automatically generated table of contents.  This is assembled using root-level page elements by name.  Anchors are built which automatically reference them from the table of contents to their app
earance on the page.  The suppress option is available when the ToC is enabled, and vice-versa.
\par 
\par }{\i Wrap / Unwrap TOC
\par }{
\par Pages with many root level elements may have a long table of contents.  When the TOC is activated (see above), this toggle becomes available
.  Wrapping the TOC will cause it to be displayed in a two column table, with the first half of the TOC in the left cell and the second half in the right.
\par 
\par }{\i Clear Copy Buffer
\par }{
\par This option becomes available when an element, or generational lineage, is copied.  If the buffer is currently empty, this option is nowhere to be found.  There are advantages in leaving it empty.  It offers a slightly less \ldblquote noisy\rdblquote 
 authoring mode (the paste buttons all go away), and reduces the chance of a page error.  For example, if the author has copied a damaged parent-child relationship or something interesting happens which might affect the buffer.  
\par 
\par One such interesting case is that an element in the buffer (the buffer, remember, points dynamically back to each source table: res
ource, staff person, etc.) is deleted. Buffers are affected by this procedure.  Elements in buffers, as well as on pages, reference keys in their host tables.  If the key is lost, then the element is converted \endash  behind the scenes \endash 
 both on all affected pages as well as in all user copy-buffers to a \ldblquote text label\rdblquote  type element.  The source element\rquote 
s title, URL, and description (if any) are inserted into the corresponding text label fields.  When a Manager deletes such a component, there is the capability to ad
d a message why the element was deleted.  This message is automatically concatenated to all occurrences on pages where it once existed \endash  as well as in all instances of user copy buffers.  So this procedure shouldn\rquote 
t cause any problems, but it\rquote s usually better safe than sorry.  Thus, the recommendation that buffers be cleared after a copy/paste procedure is completed.
\par 
\par This is a particularly complex set of logic, approaching \ldblquote rocket science\rdblquote  proportions.  But it can be avoided if (a) People avoid deleting th
ings that are currently used on CLPS pages (instead, they first instruct Authors to remove such items beforehand) and (b) they encourage people to leave their copy buffers empty.  For resources particularly, at the point of deletion there is the option to
 
check the Resource Detail page (also available on the Author console as a resource drilldown (the user must supply the resource ID) which will explain system demographics for the affected resource.  Here they may be removed from their occurrences in CLPS 
prior to their deletion from the base resource table.
\par 
\par }{\i Activate Up Anchors / [Up] anchor text / Save [Up] Text
\par }{
\par For pages with especially long chains of siblings before additional root uncles & aunts are encountered, it may be useful to automatically generate anchors which refer back to the top of the page.  The text up the \ldblquote up anchor\rdblquote 
 may be customized (and the \ldblquote Save [Up] Text\rdblquote  button must be clicked.
\par 
\par }{\i Apply Style
\par }{
\par Styles affect page appearance with a header, footer, and cascading stylesheet.  Styles are configured in the Manager Functions menu where they must reference actual files in the supplied directories.  The
 CSS file must have span classes S1, S2, S3, S4, and S5 which are explained further in this section and more fully in general in the LibData Customization document.  The style should be chosen, and then the \ldblquote Apply Style\rdblquote 
 button must be clicked.
\par 
\par }{\i Page Font Format
\par }{
\par Numbers here refer to the currently selected style, and the special S1, S2, S3, S4, and S5 span classes which must be present in it.  Note that the libdata.css stylesheet (the default) has a basic set of them, but new styles can have their own vari
ants.  The Page Font Format option, in general, allows an author to select a level of elements and apply a particular style en masse, rather than clicking each individually.  This will be explained after reading further below.
\par 
\par \tab }{\i Level
\par }{This refers to the generational level of the elements for which the style is to be applied.  Root-level elements are 0.  Their children are 1, grandchildren 2, and so on.
\par 
\par \tab }{\i Style
\par }{The previously mentioned special span classes in the selected style sheet (libdata.css is default)
 can be cycled through here.  Refer to the LibData Customization document for a full discussion of how they may be configured.  Unlike a fully-robust word processing system, we have not implemented individual toggling of font size, italics, bold, underlin
e, face, etc.  Rather, these are bundled in up to 5 variations (in addition to the BODY default style).  So styles 1-5 here should reflect 5 bundles of text characteristics.  Our other interest in doing this was to purposely }{\i reduce}{
 the font variations possible on a page, since numerous text changes on web pages quickly produce a cluttered rendering.
\par 
\par \tab }{\i Apply Format
\par }{Once a particular level of page elements and style type is selected, this button may be clicked to apply it en masse.  This is a quick way of changing the appearance of generational siblings by issuing a single command.
\par }{\i Assign Page Staff
\par }{
\par This option causes a new window to appear which handles page authorizations.  The window persists until it is closed, or some other command (outside of the window)
 is performed.  (This is not an annoying javascript pop-up, but rather an integral part of the authoring mode.) 
\par 
\par \tab }{\i Reassign Coordinator
\par }{Page creators are the default coordinators.  It\rquote s possible to for authors to remove themselves from the position of coor
dinator.  However, if they do not first name themselves as a co-maintainer, they are now locked out of their own page.  Managers can safely name a new coordinator from someone else in their Library Unit (assuming they are Unit Lead).  DBA\rquote 
s can reassign coordinators willy-nilly and still have access to the page.
\par 
\par \tab }{\i Add/Remove Maintainers
\par }{Maintainers can be added and removed as required.  Once added to a page, they have full access over all page functionality, including the ability to usurp a position as coordinator or delete the page entirely.
\par 
\par \tab }{\i Close This Window
\par }{This option closes the assign page staff window.  It will close automatically if some command is conducted outside the window.
\par 
\par 
\par }{\b Inline Element & Icon Explanations
\par }{
\par }{\i Page Title
\par }{
\par The title of the page may be changed here.  Don\rquote 
t include HTML tags in the title field.  Compare this field with CourseLib titles.  CourseLib pages use the title field to store the name of the course.  But the full title of any CourseLib page is a concatenation of the following (see }{\b 
5.3 CourseLib Authoring}{ for additional comments):
\par 
\par \{course subject \endash  required to publish\} \{course number\} \{course title\} \{course section\}
\par 
\par 
\par }{\i Page Header
\par }{
\par (Available only for PageScribe pages).  This field may contain any sort of text or HTML.  In fact, it\rquote s possible to build a page with no page elements at all \endash  and just display the contents of this field.
\par 
\par }{\i Green \ldblquote Plus\rdblquote  Icon
\par }{
\par This is the add-an-element symbol.  As discussed in various sections above, there are parent-child relationships at work.  The add icon is available only in legal positions.
\par The sorts of elements which may be added include the following:  Resource, Location, Staffperson, Service, Free text wrapped with an optional URL, a link to an RQS page, or the en masse ha
rvesting (in alphabetical order) of all resources on the selected RQS page.
\par 
\par Options available each of these categories are sometimes defined only by a Manager or DBA (for example, services or library/locations, or staff).  Or they may be the result of the work of Authors (RQS pages, resources).
\par 
\par Note that newly added elements maintain the title, URL, and description of their source or base table.  Library Location has special functionality.  If an URL was supplied to the base table to indicate a map or hou
rs web page,  special bulleted links appear after the Location description (if present).
\par 
\par Free text labels are interesting in that they may contain HTML in both their title and description fields.  It\rquote s even possible to use IMG SRC to reference an image lo
cated elsewhere to incorporate images within PageScribe pages.  Note that there is currently no facility to upload multimedia directly into LibData.  Rather, the model here is that a multimedia library should be maintained by someone with an interactive u
nix account and expertise with permissions, naming conventions, file size maintenance, etc.  So with a little coordination between an Author and a media library and web designer, it\rquote 
s possible to produce some fairly graphically rich PageScribe/CourseLib pages (sound files can be referenced in similar ways).  We\rquote 
ve also dumped page source of entire flat HTML page sources into free text description fields (up to 64K limit) to essentially render a page within a single PageScribe element.
\par 
\par }{\i Yellow Box Icon
\par }{
\par This is the edit icon.  The current element, page title, or CourseLib course-related field may be edited with this command.
\par 
\par If the edit command involves a page element, it may be edited for a unique description.  The initial description, as with RQS, is t
he description (hopefully a default description was supplied) from its source table.  If the user wants to make changes to it, the text may be edited and the changes Saved.  Failing to click \ldblquote Save\rdblquote 
 will result in loss of changes.  So descriptions for eleme
nts have one of two statuses: default/dynamic or custom/static.  Changing to a custom description means that changes to the record in the base table will no longer filter down (except element title and URL if any).  It\rquote 
s possible to revert back from a customized description to the default description by deleting the entire description (including all trailing spaces, carriage returns, etc.) and saving the changes.
\par 
\par If, for whatever reason, a page author wants neither the default description nor a custom description \endash  to have no description at all \endash  we recommend saving a single white-space as a sort of \ldblquote hidden\rdblquote 
 custom description to override the displaying of the item\rquote s default description (but this is a rarely used scenario and we\rquote ve never encountered such a need).
\par 
\par Note that text-type elements have additional fields which may be edited: label (title), and an optional URL to wrap around the label.  The description of free text/label fields is of course always static/custom since there is no source table involv
ed.  They are part of the element itself.
\par 
\par Note that deleting a source record in the resource, service, location or staff tables results in behind-the-scenes conversion from all instances on all CLPS pages from dynamic to static/text type fields.  This is 
a fairly destructive process, so we recommend that dependent CLPS page elements be authored-out before a deletion occurs (as discussed earlier).
\par 
\par }{\i Red Box Icon
\par }{
\par This is the delete element command.  Not to be confused with deleting from the source table, thi
s merely deletes the currently-selected element and makes necessary adjustments (if any) to descendants.  Note that deleting can work one of two ways if descendants are present.  Two options are given in such cases: descendants may be deleted recursively 
along with the selected parent, or they may be \ldblquote promoted\rdblquote  as parents.  This has a cascade effect along the lineage, promoting each generation by one level.
\par 
\par }{\i Copy (Page/Page) Icon
\par }{
\par Elements may be copied individually or, if children are present, the entire lineage as a group may be copied.  Each user has a buffer unique to them, and it remains even after the user has logged out.  In fact, it\rquote 
ll remain into perpetuity until the user account itself is deleted.  Copying an element(s) causes the \ldblquote clear copy buffer\rdblquote 
 button to become available in the overall page commands table, and places a paste icon (see below) next to any legal add position.
\par 
\par Programmer\rquote s Note:
\par Recall discussions elsewhere in this document about the deleting of source records and how this affects paste buffers (for }{\b example 5.2 PageScribe Authoring: Clear Copy Buffers}{).  So it\rquote 
s probably good practice at this point to use this function only when it warrants, and not hold buffers into perpetuity.  Although we\rquote re aware of no bugs with the conversion
 of relational to text type elements on the fly in user copy buffers should a source record become deleted, it might be safer had we implemented automatic deletion all affected user buffers entirely.  That is, no nifty conversion from relational to static
 on the fly.  But we\rquote ve went the \ldblquote extra mile\rdblquote  here and hope that we haven\rquote t run out of gas in the process...
\par 
\par }{\i Paste (Page/Clipboard) Icon
\par }{
\par If one or more elements are currently in the user\rquote s copy buffer, the paste icon becomes available wherever a green add
 icon is located.  Paste will insert all copied elements at the selected position, and can be done repeatedly.  If there are descendants, they fall into relative place.
\par 
\par }{\i Style [X] [1] [2] [3] [4] [5]
\par }{
\par This corresponds to the Page Font Format detailed in Overall Page Commands above.  Rather than setting elements of a particular generation en masse, they may also be tweaked individually with this method.
\par 
\par The numbers 1-5 correspond with underlying style classes S1, S2, S3, S4, and S5 that a Manager has developed (according to suggestions in the LibData Customization document) in the currently selected page style.  So there are really two meanings of 
\ldblquote styles.\rdblquote   The page style itself, which encompasses a header, footer, and CSS.  And the particular style class (S1-5) which should be applied to a particular element.  Note that \ldblquote x\rdblquote 
 denotes no style.  The currently selected style will be boldened to set it apart from the others.
\par 
\par }{\i Up Arrow / Down Arrow
\par }{
\par Elements may be moved up or down to swap places with a peer sibling.  This has the effect of moving all descendants (if any) along with the element moved.  These arrows are available only where such moves are legal.
\par 
\par 
\par }{\b\fs28 5.3\tab CourseLib
\par }{
\par }{\b Relationship to PageScribe
\par }{CourseLib relies on the same editing engine used by PageScribe, so all of the functionality in }{\b 5.2 PageScribe}{ above apply here.  The subtleties with regard to }{\i Publishing}{
 CourseLib pages (they then appear on the public side CourseLib interface) and }{\i Page Titles}{ o
f CourseLib pages have been discussed above.  As a reminder with regard to title, CourseLib titles are the title of the course (e.g. Introduction to Biology).  The full title is concatenated in a back-end field to store course department (required for pub
lishing the CourseLib page), course number (if supplied), course title (required), and course section (if supplied).
\par 
\par 
\par 
\par 
\par }{\b Additional Fields
\par }{CourseLib pages, in authoring mode, have additional fields (those previously mentioned) plus slots for introductory comments, headers, etc.  These are all optional.  HTML tags may be wrapped within text-type fields.
\par 
\par }{\b Adding Personnel
\par }{Requiring further explanation here is the Add Personnel feature.  This is not to be confused with page staff (those who may have the ability to edit/delete this page), but rather instructor personnel associated with the CourseLib page.
\par 
\par A title (e.g. professor, lecturer, etc.) may be chosen}{\b .  }{Refer }{\b to 6.0 Manager Functions }{\i Staff Title }{
for further explanation of this field.  Then, it is possible to select either a LibData staff person (to use here as a course instructor), or a faculty person.  Both of these pick-lists are maintained by Managers.
\par 
\par Another possibility is the capability to add faculty and TA\rquote s on the fly (we\rquote ve thought of everything, haven\rquote t we!).  It\rquote 
s possible for a CourseLib author to create a new faculty person with this method.  Note, however, that Authors may not edit or delete from the faculty table}{\i .  So if an Author makes a typo here, it must be cleaned up by a Manager or DBA}{
.  This limitation was programmed deliberately.  Once the firstname/lastname/directory account/email have been filled out, the CourseLib author must select Faculty or TA/Other (default selection i
s Faculty).  Faculty entries are indexed in the faculty table and may be reused.  TA\rquote s are expendable.  Note that they may still be searched by name substring from the CLPS administrative search screen \endash 
 but there is no controlled list or vocabulary present for them and they may not be reused by LibData.  So if a lecturer is likely to teach more than one course, they may better be placed in the Faculty table at this point of creation.
\par 
\par 
\par }{\b\fs28 6.0\tab Manager Functions
\par }{
\par As briefly discussed under }{\b 2.0 System Accounts}{
, Managers have an additional link available at the bottom of the Author console which will allow them to enter the Manager Functions screen.  This is a collection of setup and mapping tables which provide a controlled vocabulary and maintain relationship
s between various sorts of data.
\par 
\par Keep in mind that this is a fully relational database system.  It would be worthwhile for managers to glance at the LibData E-R diagram, which graphically illustrates the connections between tables.  There are many dependen
cies between tables, and LibData can maintain the technical side of relationships.  But maintaining a meaningful installation requires careful human attention.
\par 
\par }{\b IMPORTANT}{: Many tables have an initial \ldblquote (N/A)\rdblquote  row in them.  This is important, and should not 
be deleted.  This is sort of the catch-all row to handle non-assigned situations.  Its underlying primary key ID is always #1 and the system is sensitive to this.  The staff table, in addition, has a special slot (#2) for the System Administrator.  Occasi
onally there may also be an \ldblquote All\rdblquote 
 category.  Generally these should be left alone and in most cases are not even displayed for editing purposes.  But anyone going into the mySQL tables directly may see these entries.  As a rule of thumb, N/A, All, or System
 Administrator (in the staff table) should not be deleted.  If they should become deleted, bugs might crop up and someone would probably have to go into mySQL directly to manually INSERT a row in the #1 primary key slot for the affected table again.  Gene
rally the LibData Manager interface will not allow these rows to be deleted, so this information pertains to anyone going into the \ldblquote back end\rdblquote .
\par 
\par General comments on the interface \endash  it\rquote s designed to be strictly functional, no work to jazz it up.  Clicking \ldblquote New\rdblquote 
 brings the Manager directly to the appropriate form to create a new entry for that type of record.  Most records have an enforced uniqueness rule on the \ldblquote title\rdblquote  or label of the entity, so this workflow shouldn\rquote 
t be used if there\rquote s a possibility that the row already exists in the table \endash  it\rquote ll result in a failure message.  The better workflow would be to click the corresponding \ldblquote Search\rdblquote  button.  Note that an asterisk 
\ldblquote *\rdblquote  will display all rows in the table, and the desired row may then be selected with its adjacent radio button.  If the table is quite large, it\rquote s better to search for substrings.  For example, entering \ldblquote ology
\rdblquote  in the subject field would bring up a quick list of Anthropology, Biology, Geology, Zoology, etc. if these were present in the underl
ying table.  This strategy can be employed against all of the Manager setup tables with a search/limit capability.
\par 
\par Some forms, when saved, then result in additional forms becoming available.  Since this is HTML, remember that forms cannot be imbedded within forms \endash 
 so a screen with multiple forms might present some confusion for people.  Take the resource form as an example.  When a resource is saved, three additional forms become available: the assigning of a location/library, features, or master subjects
.  If a user has written an extensive annotation on the resource form, failed to save it, and then decides to assign a new feature, s/he will lose any unsaved changed in the resource form as the HTML is redrawn from the back-end database.  Some user train
ing is essential here to avoid this.
\par 
\par Assignment-type forms have a \ldblquote Available\rdblquote  selections box on the left and a \ldblquote Selected\rdblquote 
 set on the right, with left and right arrows under both of them.  This is fairly intuitive and standard.  In most cases, multiple selections are possible with the control and shift keys.  The boxes generally contain mutually exclusive sets of data.

\par 
\par }{\b A note on nomenclature to clear up confusion:}{ we\rquote ve gone through some iterations with labels, and not everything is cleaned up \endash  Information Type or Subject may also be referred to as \ldblquote Base Information Type\rdblquote  or 
\ldblquote Base Subject\rdblquote  respectively.  General Information Type and General Subject may also be referred to as \ldblquote Master Information Type\rdblquote  or \ldblquote Master Subject\rdblquote  respectively.
\par 
\par }{\i Information Type
\par }{
\par Also referred to as a \ldblquote base information type\rdblquote  on the Resource form and in other places.  This would be equivalent to the species in a Linnean classification schema of Homo sapiens.  It\rquote 
s the more specific of the two tiers of classification.  We initially exper
imented with three (or possibly unlimited) layers but it became a usability and management issue.  How many layers are required to strike various balances?  We found that two were adequate for our purposes.  Information Types are associated with a General
 (Master) Information Type and a General (Master) Subject.
\par 
\par It\rquote s important to build the associations, since they create the information hierarchy obeyed by RQS pages.  Resources should be assigned (on the resource-entry form) to a base information type so that they become \ldblquote smart\rdblquote 
 and float exactly to this default position on the two-tier hierarchy on RQS pages when they are added to them.  Note that the General Information Type of Resources is inferred by the system behind-the-scenes by examining the resource\rquote 
s base information type and then, in turn, hunting for its general information type.  So properly assigning resources to an information type, and building the associations are essential and reduce work in the long run.
\par 
\par }{\i General Information Type
\par }{
\par Information types are associated with exactly one General (Master) Information Type.  This is the genus portion of the information hierarchical consideration.
\par 
\par }{\i Subject
\par }{
\par These correspond to RQS subject pages.  Note that subjects can be assigned a primary location and description \endash  these are both used by RQS to draw public side pages.  Once the subject has been saved, additional forms become available.
\par 
\par Subjects may be assigned to one or more General (Master) Subjects.  Note that where base Information Types have only a single General Information Type, Subjects can be mapped to multiple Master Subjects.
\par 
\par Secondary locations are then also possible to assig
n. Note also that the locations/libraries for secondary status (also appearing on RQS public side pages) includes the primary location (if any) as well.  So be careful not to redundantly select a location for both primary and secondary.
\par 
\par Staff may be assigned to edit/maintain the RQS page here.  Note that anyone authorized to edit a subject may remove themselves or add other people to it.
\par 
\par Mapping to CIP codes requires some explanation \endash  at the University of Minnesota we\rquote re experimenting with a portal compo
nent such that an incoming course subject (for example ANTH) or its equivalent CIP code can be mapped to an RQS subject.  We then have a mechanism to push a simple XML-wrapped set of RQS subjects with URL\rquote 
s back to the portal.  Thus, a student logging into some other campus/enterprise application might be \ldblquote pushed\rdblquote 
 appropriate RQS pages based on courses s/he is registered for.   Since this is unique to our institution it is not part of the LibData open source release.  But the basic concept involves simple \ldblquote listening\rdblquote  and \ldblquote sending
\rdblquote  PHP functions.  A portal-related page accepts an URL query string parameter for CIP or course subject, and outputs in XML the mapping results.  These might be parsed by the portal the user is logged into for presentation.  This is 
still in development, but much of the infrastructure has been developed.  So the cross-talk mapping which this functionality relies on may be done here.
\par 
\par }{\i General Subject
\par }{
\par The very broad research areas which may contain one or more base subjects within.
\par 
\par }{\i Location
\par }{
\par This may be a library, archival unit, etc.  As mentioned in the CLPS authoring section of this document, note that the location\rquote s map and hours URL (if supplied) will appear as special bulleted links following the location\rquote 
s description on CLPS pages.
\par 
\par }{\i Feature
\par }{
\par This is a generic catch-all category for things like Free, Restricted, Full Text, etc.  Note that it includes the ability to reference an icon and create some HTML ALT text.  When an RQS page is rendered on the public side containing resource
s with assigned features, the appropriate icon(s) are displayed (with underlying ALT text) alongside the resource title.
\par 
\par }{\i Service
\par }{
\par Library Services, once saved in LibData, have two additional forms.  They may be mapped to location(s) (see discussion above)
 and they may be associated to a Service Type (see below).  If your Library has a large array of services, they may be categorized (Reference, Borrowing, ILL, etc.).  This allows them to be limited by other applications designed to extract them, outside o
f LibData.  Also take note that Services added as elements to a page in the CLPS environment may be limited for easier selection by service type.  Again, this feature is probably most useful to large institutions.
\par 
\par }{\i Service Type
\par }{
\par See discussion of Services above.   This allows specific services to be grouped together into clusters based on business/functional or some other similarity.
\par 
\par }{\i Vendor
\par }{
\par Resources may be associated with a vendor/provider.  This is useful for both the administrative and public sides of LibData.  The Advanced Search page for resources allows limiting by vendor, which can provide for a useful management tool.
\par 
\par Vendors occasio
nally experience technical downtimes, and this may be indicated on the vendor form within LibData by clicking the appropriate vendor status: Up, Down, or Alert.  Down and Alert both allow for messages in the Down/Alert box to be displayed alongside all as
sociated resource titles on RQS and CL/PS pages.  The message is accompanied by a small graphic supplied with LibData to bring attention to the user that the link may be experiencing problems.
\par 
\par Note also that resources may be individually flagged as Up, Dow
n, or Alert, with an accompanying resource-specific Down/Alert message.  This allows for circumstances in which some vendor resources are available, and others are not.  If a resource is flagged Down or Alert at both the resource and vendor levels, the ve
ndor message will take precedence.
\par 
\par }{\i PageScribe Style
\par }{
\par This is discussed at length in the LibData Customization document.  Of special interest here is that LibData currently does no error-checking on the specified files for header/footer/css.  They need to r
eside in the specified location, and be set with appropriate file permissions.  The creation and design considerations are discussed in the Customization document.  Libdata.css, part of LibData standard, could be used as a template for cloning purposes.  
T
he only requirement for these files is that the CSS must contain special S1, S2, S3, S4, and S5 classes so that element-level style specifications applied in the CLPS authoring environment have corresponding SPAN classes in the supplied CSS.  Beyond this,
 anything may be customized in the CSS file.
\par 
\par }{\i Campus
\par }{
\par Used when creating CourseLib pages.
\par 
\par }{\i Term
\par }{
\par Academic term.  Also used when creating CourseLib pages.
\par 
\par }{\i Course Subjects
\par }{
\par The list of subjects, typically accompanied with abbreviation by most all academic institutions.  They may  be assigned to a specific campus as well.  CIP code is optional and not currently used by LibData.  However, refer to the discussion under }{\i 
Subjects }{in this section for how a mapping between Course Subjects and RQS subjects might facilitate some interesting portal functionality.
\par 
\par }{\i Faculty
\par }{
\par These are used on CourseLib pages and may be assigned/removed from those pages as desired.
\par 
\par }{\i Staff Title
\par }{
\par A list of titles, used by both faculty and staff.  This
 is particularly useful when plopping faculty to CourseLib pages.  A title (professor, associate professor, assistant professor, lecturer, etc.) can be associated with the selected faculty person.  Note that staff titles in the staff table are not used in
 
the public interface.  Scenario: a librarian also happens to be a tenured faculty member.  S/he is going to be an instructor on a CourseLib page.  When a LibData staffperson is added as an instructor for a CourseLib page, the title of the staff person as 
it appears in the Manager Functions staff table is }{\i not}{ used.  Rather, it may be selected anew here.  This was allowed since many of us wear multiple hats.  Refer to section 5.3 on CourseLib authoring for this functionality.
\par 
\par }{\i Library Units
\par }{
\par These are work un
its with a unit lead, who should have either the Manager or DBA access level in LibData.  Once the Library Unit is saved, an additional form pops up which allows the selection/removal of staff assigned to that unit.  Note that any manager may make changes
 to any other unit.  (This requires a collegial level of trust, or some additional security-related programming to rectify.)
\par 
\par }{\i Staff
\par }{
\par \tab }{\i Manage Staff
\par }{This option brings up a tabular list of all staff currently part of the LibData system, access, whether they h
ave a password assigned, last date and IP address of login, etc.  Note that once a new staff person has been assigned, several additional forms are available.
\par 
\par The setting and purging of passwords.
\par 
\par The assignment/removal of that staffperson to library uni
ts.  Note that this function is the same (but from a staff-centric perspective) to the assignment form under Library Units above.  From that perspective, a given library unit may add/drop staff members.  From this perspective a given staff person may be a
dded/dropped from units.  Staff may also be assigned various subjects here.  Note, also, that the Subject table has the ability to add/drop staff from it, affecting staff as well.
\par 
\par \tab }{\i RQS Assignments
\par }{This is a handy Manager-level tool which displays all staff<->subject assignments for managing RQS pages.  Staff appear on the left, subjects on the right.  A \ldblquote public\rdblquote 
 flag is either Y or N, depending on whether the subject in question has been published and it publicly available on the patron RQS interfaces.
\par 
\par When a staffperson (left-most column in this table) is \ldblquote clicked\rdblquote , the edit-staff form for that person is brought up.  From there it\rquote 
s possible to add/subtract assigned subjects.  On Or, when a subject (right-most column) is clicked, the subject-edit form is b
rought up.  From there, staff may be add/dropped from that subject.  So there are numerous ways to perform similar tasks, and they make sense depending on what the manager is doing (working on a particular subject vs. on a particular staffperson).
\par 
\par 
\par }{\b\fs28 7.0\tab DBA Tools
\par }{
\par }{\i RQS Subject <-> CIP Code Crosswalk
\par }{
\par This tool allows DBA\rquote s to conveniently map any RQS subject to academic course subjects.  As was discussed under }{\b 6.0 Manager Functions \endash  Subject}{, there is the capability to map RQS subjects against academic cours
e subjects (or departments).  There is currently no public application with LibData Rel. OS 1.0 that takes advantage of this mapping, but such things would not be difficult to build should the need arise.
\par 
\par One possibility is to simply limit your entry of RQS subjects to mirror 1:1 the academic environment, then no mapping exercise will ever be necessary.  But we\rquote ve found that it\rquote 
s useful to be able to create new library subjects which either are cross-disciplinary, more timely than the ability of the Univer
sity to re-organize its academic departments, or subjects which really have no corollary with a particular department.  Thus, this tool is available.  Taking advantage of it rests with each institution\rquote s unique situation.
\par 
\par }{\i Resources Lacking Default Information Types
\par }{
\par This screen allows for display of all resources which have no assigned default base information type.  These resources will not \ldblquote float\rdblquote  to their proper place when added to RQS pages, and will always need to be m
oved manually out of the (N/A) category into something that makes sense.
\par 
\par }{\i LibData System Status
\par }{
\par A short assembly of queries to report on the current status of the system: number of unique staff who\rquote ve logged in today, number of cataloged resources, CLPS p
ages, etc.  Any additional status queries developed by a database programmer might be added and displayed to LibData DBA\rquote s here.
\par 
\par }{\i CourseLib Debugger
\par }{
\par Select the desired CourseLib page and run several integrity tests on it.  If a page begins to behave poorly, it\rquote 
s most likely an internal error with the parent-child relationships.  This debugger will hopefully aid in making that determination.  Should an error(s) be found, there are intelligent fix options available.
\par 
\par Note that while LibData is tightly normalized, some problems can occur if two users are working on the same page \endash  }{\b we have no concurrency checking!  }{
Thus, the best way to avoid this problem is to distribute authoring assignments carefully.  Should a page become damaged, undamaged portions may be 
copied out and pasted to a new page.  Another possibility is to rebuild the page from scratch.  Sometimes an error may be fixed by cloning the entire page \endash 
 the new page is rebuilt such that element orders and parent-child references are re-calculated.  (However, errors shouldn\rquote t be very common.  We have gone six months in a large Big-10 university library environment and found only a single error.)

\par 
\par If the debugger locates an error, some information about the nature of the problem will be displayed, and th
ree fix options will become available (these options are not offered if no errors are found).  They range from least to most destructive to the page:
\par 
\par (1)\tab Attach orphaned elements to most likely parent.  This method will hunt out the element which is most appropriate to be a parent.  For example, an earlier occurring element with an indent/generation level exactly one less.
\par (2)\tab Delete orphaned elements and their children.  Simply remove the problematic element and its lineage.
\par (3)\tab Purge all parent-child relationships, and move all elements to root-level position.  This method is most destructive, but almost guaranteed to fix a broken page.  It destroys page hierarchy, but preserves the selection of elements.
\par 
\par After whichever method is chosen, the page elemen
ts are both adjusted for both order and parent-child cohesion.  The page fix mechanism will suggest that the page debugger be re-run for a final check.  If errors are still found, the same fix method should be attempted again \endash 
 or perhaps a more severe method (#2 or #3) might be employed.
\par 
\par In general, errors are very rare and we\rquote ve been able to fix them all with method #1.  We\rquote re still working on a page authoring concurrency/locking mechanism.  But since errors are rare and this fix tool is robust, it isn\rquote t
 a high priority item.
\par 
\par }{\i PageScribe Debugger
\par }{
\par Same as above, but the pick list produces PageScribe pages only.
\par 
\par 
\par }{\b\fs28 8.0\tab Statistics
\par }{
\par }{\b Levels of Statistics & Trade-offs
\par }{There are two main methods at collecting statistics in LibData.  Every time a CLPS page is loaded, an entry is logged in the libstats table.  Every time an RQS subject page is loaded, an entry is logged for it as well.  With CLPS we\rquote 
ve gone a step further and implemented an exit counter, to get a feel for resource utilization down to the element level on CLPS pages.
\par 
\par Unfortunately, this has the detrimental side-effect of hiding URLs when the user passes his/her mouse cursor over a link.  Rather than seeing the resource\rquote s own URL, the link.phtml file is referenced \endash 
 and this takes the element and page ID are as incoming parameters.  These allow the LibData statistics module to collect link usage.  LibData then redirects the patron\rquote s browser to the actual reso
urce URL.  The undesirable side-effect may be easily stripped out by a programmer familiar with PHP \endash  but the trade-off is that element-level statistics are no longer available.
\par 
\par Since HTML is a stateless protocol, there is no way to determine where a user goes once a web page is loaded into his/her browser \endash  unless is \ldblquote checks back in\rdblquote  with the server.
\par 
\par }{\b A word of general caution
\par }{The statistics tables were purposely stored into a separate database (libstats) because they grow at unpredictable rates.  And performance may become an issue on the dynamic \ldblquote roll up\rdblquote 
 screen display all pages and element utilization per page.  If this happens, a number of options are available:
\par 
\par (1)\tab The statistics tables should be purged on a regular basis (this requires someone familiar with SQL to enter the libstats database and DELETE FROM the three statistics tables there).
\par 
\par (2)\tab Some programming modifications might be done to the statistics \ldblquote roll up\rdblquote  page which displays all element utilization \endash  i.e. display only use statistics fo
r a particular page.  First require users to select a page, then show only its rollup, rather than an entire system-wide rollup.  This will substantially cut down on query load.
\par 
\par (3)\tab Don\rquote t do anything at all.  Recognize that this is a computational intensive process.  Simply print out statistics in a static format on a scheduled basis.
\par 
\par }{\b Relational Comments
\par }{Elements in the statistics tables are still tied, relationally, to their source records.  If Google, for example, is a resource on a CLPS page and is del
eted by an Author of that page, its statistics are likewise deleted.  So this table currently maintains no historical statistics usage.  This presents a few problems and, like many other things, we\rquote re working on various solutions.
\par 
\par Probably the most desirable solution is to simply not write statistics out to a table at all, but rather a log file \endash  and build an application that\rquote ll analyze the logs.   This requires convincing a unix administrator that it\rquote 
s not a security risk to grant PHP the ability to interact at this level with the file system...
\par 
\par 
\par }{\b\fs28 9.0\tab Patron Interfaces
\par }{
\par The following public interface pages/modes are currently enabled with this release of LibData.  In-house pages may be easily developed with basic SQL queries.  For example, a page to displa
y, in tabular format, all libraries and their telephone numbers is trivial \endash  so the number of patron applications that LibData might drive is enormous, since the data set is rich and (if populated as such) can be highly relational and associative.

\par 
\par }{\b RQS Subject Selection Page (subjects.phtml)
\par }{
\par Users select from the combo-box which RQS subject page they\rquote d like to view, or limit the box to subjects beginning with a particular letter A through Z.
\par 
\par }{\b RQS Subject Page (rqs.phtml)
\par }{
\par The RQS page itself.  This is the default page: for screen display, and all resources associated with this particular subject.  Note that there are 4 permutations possible, based on values of incoming URL parameters \ldblquote core\rdblquote  and 
\ldblquote pf\rdblquote .
\par 
\par screen & all resources\tab \tab Default rendering.
\par }\pard \s16\fi-2880\li2880\widctlpar\adjustright {screen & core only\tab Display only highlighted or \ldblquote core\rdblquote  resources (refer to 5.1 RQS Authoring).
\par }\pard \s16\widctlpar\adjustright {print-friendly & all resources\tab This version omits the table of contents and page header
\par \tab \tab \tab \tab (which will likely contain institutional graphics, logo, etc.).
\par print-friendly & core only\tab The print-friendly version of only highlighted or \ldblquote core\rdblquote 
\par \tab \tab \tab \tab identified resources.
\par 
\par }{\b CourseLib Selection Page (courses.phtml)
\par }{
\par Shows a pick-list available CourseLib (not PageScribe) pages in the system.  The combo select box may be limited to cour
se titles beginning with a particular letter, substring search for department or title, or controlled lists of course department and professor name.  The user picks from the combo box, limited by search criteria or not, and loads the specified CourseLib p
age.
\par 
\par Note that there is no pick list of PageScribe pages.  We\rquote ve felt that, unlike CourseLib, they have nothing inherently in common with one another other than the tool that created them.  Thus, we\rquote 
ve not yet found the need to create a pick list of them.  Such a list would be easy to make, however.
\par 
\par }{\b CourseLib / PageScribe Page (page.phtml)
\par }{
\par This PHP file loads CourseLib and PageScribe pages, based on an incoming page_id parameter.
\par 
\par }{\b CourseLib / PageScribe Print-Friendly Version (page_print.phtml)
\par }{
\par Unlike the print-friendly version of RQS (see above), this is not merely toggled with an incoming URL flag.  Differences were significant enough such that it was decided to maintain two separate URL\rquote 
s at this point in LibData development.  Print-friendly pages of CourseLib and PageScribe display the URL\rquote 
s of page elements, and e-mail addresses of staff as elements whenever possible.  This way, they may be printed and are still visible on hard copy.
\par }{\b\fs28 10.0\tab Conclusion & Credits
\par }{
\par LibData is clearly a work in pro
gress, as it has been since 1997 when the first iteration of Research QuickStart and 2000 when the first version of CourseLib were implemented.  It was our desire here to create something highly functional, much more robust and integrated, with a great de
gree of customizability, and own it in-house.  This project resulted from many hours of brainstorming sessions by members of the LibData Design Committee, and countless liters of coffee by the programmer on the project. 
\par 
\par We hope that by giving it all away (free of charge, but with no warranty or guarantees stated or implied) that it may be used and improved upon by other institutions, as we continue to do so ourselves.
\par 
\par Core LibData design staff at the University of Minnesota:
\par 
\par Paul Bramscher (LibData programmer) }{\field\fldedit{\*\fldinst { HYPERLINK "mailto:brams006@tc.umn.edu" }{\fs20 {\*\datafield 
00d0c9ea79f9bace118c8200aa004ba90b0200000017000000140000006200720061006d0073003000300036004000740063002e0075006d006e002e006500640075000000e0c9ea79f9bace118c8200aa004ba90b360000006d00610069006c0074006f003a006200720061006d0073003000300036004000740063002e00
75006d006e002e00650064007500000000000000000000000000}}}{\fldrslt {\cs15\ul\cf2 brams006@umn.edu}}}{
\par Shane Nackerud (Web Services Coordinator) }{\field\fldedit{\*\fldinst { HYPERLINK "mailto:snackeru@tc.umn.edu" }{\fs20 {\*\datafield 
00d0c9ea79f9bace118c8200aa004ba90b02000000170000001400000073006e00610063006b006500720075004000740063002e0075006d006e002e006500640075000000e0c9ea79f9bace118c8200aa004ba90b360000006d00610069006c0074006f003a0073006e00610063006b006500720075004000740063002e00
75006d006e002e00650064007500000000000000000000000000}}}{\fldrslt {\cs15\ul\cf2 snackeru@umn.edu}}}{
\par John Butler (Digital Library Development Laboratory Lead) }{\field\fldedit{\*\fldinst { HYPERLINK "mailto:j-butl@tc.umn.edu" }{\fs20 {\*\datafield 
00d0c9ea79f9bace118c8200aa004ba90b0200000017000000120000006a002d006200750074006c004000740063002e0075006d006e002e006500640075000000e0c9ea79f9bace118c8200aa004ba90b320000006d00610069006c0074006f003a006a002d006200750074006c004000740063002e0075006d006e002e00
650064007500000000000000000000000000}}}{\fldrslt {\cs15\ul\cf2 j-butl@umn.edu}}}{
\par Kate McCready (Reference Librarian) }{\field{\*\fldinst { HYPERLINK mailto:mccre008@umn.edu }{\fs20 {\*\datafield 
00d0c9ea79f9bace118c8200aa004ba90b0200000017000000110000006d006300630072006500300030003800400075006d006e002e006500640075000000e0c9ea79f9bace118c8200aa004ba90b300000006d00610069006c0074006f003a006d006300630072006500300030003800400075006d006e002e0065006400
7500000000000000000000000000}}}{\fldrslt {\cs15\ul\cf2 mccre008@umn.edu}}}{
\par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\fs24 Jen Tantzen (Interface Designer) }{\field\flddirty{\*\fldinst {\fs24  HYPERLINK mailto:tantz003@umn.edu }{{\*\datafield 
00d0c9ea79f9bace118c8200aa004ba90b020000001700000011000000740061006e0074007a00300030003300400075006d006e002e006500640075000000e0c9ea79f9bace118c8200aa004ba90b300000006d00610069006c0074006f003a00740061006e0074007a00300030003300400075006d006e002e0065006400
7500000000000000000000000000}}}{\fldrslt {\cs15\fs24\ul\cf2 tantz003@umn.edu}}}{\fs24 
\par }\pard\plain \s16\widctlpar\adjustright \cgrid {
\par Additional members of the LibData Design Committee
\par 
\par }\pard\plain \s17\widctlpar\adjustright \fs20 {\fs24 Laura Dale Bischof 
\par Tammy Bobrowsky
\par Andrea Halverson
\par }\pard\plain \s16\widctlpar\adjustright \cgrid {Laurie Nelsen
\par 
\par 
\par }{\b\fs28 11.0\tab LibData Licensing
\par }{
\par LibData is released under GPL (}{\field{\*\fldinst { HYPERLINK http://www.gnu.org/licenses/gpl.html }{\fs20 {\*\datafield 
00d0c9ea79f9bace118c8200aa004ba90b02000000170000002500000068007400740070003a002f002f007700770077002e0067006e0075002e006f00720067002f006c006900630065006e007300650073002f00670070006c002e00680074006d006c000000e0c9ea79f9bace118c8200aa004ba90b4a00000068007400
740070003a002f002f007700770077002e0067006e0075002e006f00720067002f006c006900630065006e007300650073002f00670070006c002e00680074006d006c000000000000000000}}}{\fldrslt {\cs15\ul\cf2 http://www.gnu.org/licenses/gpl.html}}}{) licensing t
erms, which means that LibData or applications built upon it may not be sold or re-released in some closed format.  We hope that other institutions may take our work, learn from it, build upon it, and share efforts with one another.
\par 
\par We encourage institutions which opt to use LibData to acknowledge our work with something like }{\i Built with LibData}{, }{\i Powered by LibData}{, and offer a link to http://www.lib.umn.edu/digilab/.
\par 
\par }}