FCLA Homepage FCLA PURL Homepage

FCLA PURL Server
Policies, Procedures and Guidelines

This document describes policies and guidelines relevant to use of the FCLA PURL server. Some familiarity with the concept of PURLs is assumed. For a general introduction to PURLs, see OCLC’s brief introduction to PURLS or longer introduction to PURLs.
 
POLICIES & PROCEDURES
RESPONSIBLITIES OF INSTITUTIONAL AUTHORITIES
HOW TO BECOME AN INSTITUTIONAL AUTHORITY
HOW TO REGISTER NEW USERS
HOW TO CREATE A NEW PURL
NON-LIBRARY USERS OF THE PURL SERVER

DOMAINS, SUBDOMAINS & GROUPS
TOP-LEVEL DOMAINS
SUB-DOMAINS
GROUPS

GUIDELINES
WHEN TO CREATE PURLS
WHEN TO USE THE SUS DOMAIN
NAMING CONVENTIONS

 

RESPONSIBLITIES OF INSTITUTIONAL AUTHORITIES

FCLA runs a PURL server for the benefit of the SUS libraries. The goal is to combine distributed creation and maintenance of PURLs with some control over authorized users and use.

Institutional control over PURL creation and maintenance is important for at least two reasons. First, creation of a PURL implies a commitment to maintain the PURL indefinitely – this is what guarantees persistence. Second, malicious or irresponsible use of PURLs could be damaging to an institution – imagine someone changing a PURL to point to a pornographic photograph instead of a scholarly journal article.

To use this PURL server, a library must agree to become an Institutional Authority (IA) for the PURL server. An IA is responsible for PURL creation for the institution. Any SUS library may become an Institutional Authority (IA) for this PURL server, if it agrees to the following conditions:

Each IA will be given a top-level domain and one User ID with master privileges (the "Master ID") for that domain.

Only a Master ID can add registered users to this PURL server – individuals are not allowed to register themselves. Master IDs can also create new Groups and designate other individuals as authorized maintainers of the lists of members in those Groups.

The person holding the Master ID is the PURL administrator for that institution. The set of PURL administrators at any given time is considered an ad hoc group responsible for reporting technical, procedural, or other problems with the PURL server to FCLA, and for maintaining the SUS domain.

 

HOW TO BECOME AN INSTITUTIONAL AUTHORITY

The request to become an Institutional Authority must come from the Library Director. If the Library Director agrees to the conditions noted above, s/he should have staff at the library develop a set of naming conventions for the institution. When there is a draft of the naming conventions, the Director should email these to FCLA PURLadm along with the name of the PURL administrator for that institution. FCLA will contact that individual to review the naming conventions, recommended procedures, and instructions for using the PURL server.

FCLA will then:

The PURL administrator will then be able to register new users, add them to the Group authorized to create PURLs in that domain, and create new Groups corresponding to sub-domains within the domain.

 

HOW TO REGISTER NEW USERS

Only registered users can create new PURLS or modify existing PURLS. Only the PURL administrator for an institution can register new users. New users can be created only from password-protected web pages. The password for these pages will be given by FCLA only to the PURL administrator for each institution.

To register a new user, a PURL administrator must first create the user id, then add that user to the Group for the appropriate top-level domain:

 1.  Go to the (password protected) Administrators’ Page and select "Register a new user".
 2.  Enter user information requested by the form.
 3. for User ID, enter "lastname_firstname" (the user’s last name, an underscore, and first name) e.g. "smith_john". If     following this convention would create a duplicate User ID, add a middle initial or name (e.g. "smith_john_william").     User ID is not case sensitive, so "Smith_John" and "smith_john" are equivalent.
 4. for Password, enter "changeme". Password is case sensitive so be careful that caps lock is not on.
 5. for Password hint, enter "changeme".
 6.  When prompted, confirm information is correct.
 7.  When you get the message the user has been created, return to the PURL server’s home page by clicking "Go to the       FCLA PURL home page".
 8.  Select "Modify PURLs, subdomains, groups, users".
 9.  On the Persistent URL Modification Page, select "Modify group".
10.  Fill out the requested data on the "Group Modification Form 1 of 2" and click "Continue". Add the new User ID in the       "Group Members" box on Form 2 of 2 and click "Modify Group".
11.  When prompted, confirm information is correct. The new user should now be added to the group.
12.  Contact the new user and tell him or her to go to the FCLA PURL server and change his password and password prompt. The user may then begin creating and maintaining PURLs in accordance with your institution’s procedures and policy.

 

HOW TO CREATE A NEW PURL

A registered user can create a new PURL in a domain if they belong to a GROUP that can create PURLs in that domain.

  1. Using your browser, go to the resource for which you want to create a PURL, and select and copy the URL
  2. Go to the PURL server home page, and select "Create a PURL or subdomain"
  3. Enter information requested by the form.
  4. Type your User ID and Password
  5. Type the PURL, starting with the top-level domain, in the box provided, overtyping the supplied constant "/NET/"
  6. Paste the URL that you copied in step (1)
  7. In the box "Enter other maintainers", enter the Id of the GROUP authorized to maintain that PURL. This will generally be the same as the name of the lowest level domain or sub-domain.
  8. Click "create PURL"
  9. When prompted, confirm the information is correct.

In general, it is a good idea to always enter a Group authorized to maintain a PURL. That way if the creator of a PURL is on leave, changes employment, etc., someone else in the organization will be able to maintain the PURL.

 

NON-LIBRARY USERS OF THE PURL SERVER

Currently, it is recommended that Institutional Authorities restrict use of the PURL server to library staff. It is possible that in the future, non-library units on campus may want to use the PURL server for URLs under their control -- for example, if a Chemistry department had an eprint server, they might want to use PURLs for the eprints. However, at this time, while FCLA naming services are under development and libraries do not have extensive experience with PURLs, libraries should be conservative in delegating authority to create and maintain PURLs.

 

TOP-LEVEL DOMAINS

The top-level domain identifies the university library responsible for the PURL. When a library is designated as an Institutional Authority for the PURL server, a top-level domain is created for the institution. There are also top-level domains for the SUS as a whole and for FCLA. The complete list of top level domains is therefore:

/fcla/ -- for PURLs created by FCLA staff, for example to point to our own web pages
/sus/ -- for PURLs common to the SUS, for example to point to Elsevier journal titles
/famu/ -- for PURLs created/maintained by FAMU
/fau/ -- for PURLs created/maintained by FAU
/fgcu/ -- for PURLs created/maintained by FGCU
/fiu/ -- for PURLs created/maintained by FIU
/fsu/ -- for PURLs created/maintained by FSU
/ucf/ -- for PURLs created/maintained by UCF
/uf/ -- for PURLs created/maintained by UF
/unf/ -- for PURLs created/maintained by UNF
/usf/ -- for PURLs created/maintained by USF
/uwf/ -- for PURLs created/maintained by UWF

 

SUB-DOMAINS

It is a good idea to divide your top-level domain into sub-domains. For example, you may want to create a subdomain for the library as a whole, to allow for the possibility of non-library departments using the PURL server some day. You may wish to subdivide the library into departments, for example, cataloging and special collections. So, for example, two ways of setting up sub-domains in the top level domain /uf/ could be as follows:

/uf/lib/cat/
/uf/lib/speccol/

or

/uf/cat/
/uf/speccol/

See NAMING CONVENTIONS below for more information.

Domains are important because you can set permissions to create PURLs by domain. For example, you could say that Hermione and Harry are allowed to create PURLS in the top-level domain /uf/ and that Ron and Harry are allowed to create PURLs in the subdomain /uf/lib/. That means that Hermione could create the purl:

purl.fcla.edu/uf/resource1

and Ron could create the PURL:

purl.fcla.edu/uf/lib/resource2

but Hermione could not create the second PURL, and Ron could not create the first. Harry could have created both of them.

Another reason domains are important is you can use them to generate statistics (count number of PURLs added/changed by domain) and you can use them for reports, like URL checking. You might, for example, send the report of the bad links for /uf/lib/ to a different person than the bad links for /uf/math/.

A final reason domains are important is you can do redirection to other PURL servers at the domain level. That is, if UCF decided they wanted to run their own PURL server, and we had a domain for /ucf/ then we could redirect all purl.fcla.edu/ucf/ requests to UCF's own PURL server.

Any registered user with authorization to create PURLs within a top-level domain can create new subdomains within that domain. That is, if a user can create PURLs in the domain /usf/ s/he can also create a new sub-domain under /usf/. Therefore each PURL administrator should periodically review the list of sub-domains within the institutional domain, using the "Search this resolver" function for "domain information".

Whenever someone creates a new sub-domain, s/he should also request the PURL administrator to create a new Group with the same name as that sub-domain. Individuals authorized to create PURLs in the sub-domain should then be listed as members of that group.

Each IA should have a documented policy governing the creation of sub-domains, with guidelines as to when sub-domains should be created and who may create them.

 

GROUPS

New Groups, like new Users, can be created only by the PURL administrator for an institution using password-protected pages.

As a matter of practice, a new Group should be created for each subdomain within a top-level domain; procedures for creating a sub-domain should include requesting the creation of a new group with that name.

This will enable sub-domains to be managed relatively automously. For example, say there are two sub-domains within the top-level domain /unf/: /unf/lib managed by the library, and /unf/chem managed by the chemistry department. A Group "lib" is set up with authorization to create and modify PURLs in the sub-domain /unf/lib and a Group "chem" is set up with authorization to create and modify PURLs in the sub-domain /unf/chem. Registered users in the "chem" group won’t be able to create or modify PURLs in the sub-domain /unf/lib and vice-versa, nor will they be able to create or modify PURLs in the top-level domain unf unless they are also added to the Group "unf". The chore of adding registered users to the "chem" Group can be delegated to the administrator in the Chemistry department responsible for the /unf/chem sub-domain.

 

WHEN TO CREATE PURLS

There are two primary reasons for creating a PURL:
a) to help provide a persistent name for a resource whose address may change;
b) to provide a short alias for a long or complicated URL.

In general, PURLs should not be created in the following circumstances:
a) when the real address of the object is dynamically generated by a cgi program (e.g., for images in Florida Heritage);
b) when the object is known to have a PURL already (e.g., gov docs);
c) when the object is not owned, created or subscribed to by the institution (e.g. public websites).

The URL of the object should always be searched in the PURL server before a new PURL is created.

 

WHEN TO USE THE SUS DOMAIN

PURLs should be created in "SUS" as opposed to an institutional domain when the resource is commercially available. This is true even if only a single SUS institution subscribes to the resource, because the possibility exists for other institutions to subscribe in the future.

The group of PURL administrators will distribute the work of creating PURLs in "SUS" for shared resources.

 

NAMING CONVENTIONS

The first two segments of the PURL must be the name of the PURL server and the highest-level domain, e.g.:

purl.fcla.edu/uf/

The segment with the name of the PURL server is omitted in the examples that follow.

Some institutions may want to create a hierarchy of subdomains in the form:
/main-unit/department/object
e.g.
/uf/lib/dlc/book1
/uf/lib/special/book2
/uf/lib/cat/book3
This would be useful when it is expected that PURLs will be created for non-library units.

Some institutions may want to create shorter purls by omitting the main unit:
/uf/dlc/book1
/uf/special/book2
/uf/cat/book3

Some libraries may be small enough to manage without subdomains for departments:
/uf/lib/book1
/uf/lib/book2
/uf/lib/book3

All of these schemes are acceptable; the important thing is that the institution has a planned naming pattern and follows it consistently. Therefore all participating libraries are asked to submit a set of naming conventions before being allowed to use the PURL server.

In general, note that:
-- shorter and simpler PURLs should be prefered;
-- names of services (e.g. ScienceDirect, FirstSearch) should not be included in PURLs, because the service that a resource is obtained from can change.

Revised 3/1/01

FCLA PURL Home Page Go to the FCLA PURL Home Page