PURL

Welcome to your PURL administrator interface.
PURLs (Persistent Uniform Resource Locators) are Web addresses that act as permanent identifiers in the face of a dynamic and changing Web infrastructure. Instead of resolving directly to Web resources, PURLs provide a level of indirection that allows the underlying Web addresses of resources to change over time without negatively affecting systems that depend on them. This capability provides continuity of references to network resources that may migrate from machine to machine for business, social or technical reasons.
This application has been operated by Database Center for Life Science (DBCLS), Joint Support-Center for Data Science Research, Research Organization of Information and Systems.
Please feel free to contact DBCLS if you have any questions.

Choose an action to take on PURLs

Choose an action to take on users

Choose an action to take on groups

Choose an action to take on domains

PAGE TOP

Contents

1. Overview of PURLs

PURLs are Persistent Uniform Resource Locators (URLs). A URL is simply an address on the World Wide Web. A Persistent URL is an address on the World Wide Web that points to other Web resources. If a Web resource changes location (and hence URL), a PURL pointing to it can be updated. A user of a PURL always uses the same Web address, even though the resource in question may have moved.

PURLs are themselves valid URLs. Figure 1 shows the parts of a PURL. The scheme part tells a computer program, such as a Web browser, which protocol to use when resolving the address. The host part tells which machine to connect to. The next part, the PURL domain, is analogous to a path in a URL. The domain is a hierarchical information space that separates PURLs and allows for PURLs to have different maintainers. Each domain may be administered by one or more designated maintainers. Finally, the PURL name is the name of the PURL itself. The domain and name together constitute the PURL's "id".


Figure 1. Parts of a PURL

PURLs are categorized into different types depending on how they respond to a request. Most PURLs simply redirect to a another URL (the "target" URL): Those are PURLs of type 302, because they respond to a request with an HTTP response code of 302, meaning that the object of the request was found elsewhere. PURLs may also respond with other HTTP response codes. Table 1 summarizes the different types of PURLs.

It is worth noting that there are some differing interpretations of the HTTP specification and hence some decisions were made in the implementation of PURLs. For example, an HTTP server may respond with a 404 response code if a resource is not found, if it is temporarily not present or if it simply does not want to provide it to a requester. We have chosen to think of a 404 as representing a temporarily gone status and using a 410 for those resources which are permanently not resolvable. Similarly, we have noted the need for a way to ground non-information resources into the World Wide Web and supported that concept with PURLs by suggesting that any resource addressed by a 303 PURL and returning a "See also URL" be explicitly considered not to be an information resource. This decision allows physical resources (such as your car) or conceptual resources (such as the idea of a car) to be given a PURL and referred to in a sharable manner (as when using Semantic Web techniques). Where a particular interpretation of the HTTP status code definitions differs from the way an HTTP response code is used by a PURL server, we suggest interpreting the intent of PURLs via the Meaning column in Table 1.

Table 1. Types of PURLs
PURL TypeMeaningHTTP Shorthand
301Moved permanently to a target URLMoved Permanently
302Simple redirection to a target URLFound
303See other URLs (use for Semantic Web resources)See Other
307Temporary redirect to a target URLTemporary Redirect
404Temporarily goneNot Found
410Permanently goneGone


PURL servers may be accessed either by a Web user interface or a public API. PURLs and their associated domains, users, groups of users and documentation may be reached by either method. Figure 2 shows the tabbed navigation options in the Web user interface.


Figure 2. Tabbed Navigation in the Web User Interface

2. Administering PURLs

The single most important task that one can accomplish on a PURL server is the creation of a new PURL. Other administrative actions, from user, group or domain maintenance to the other operations on the PURLs themselves are secondary to that main task. This section addresses the creation of simple (HTTP redirection) PURLs and advanced PURLs, along with the other things that may be done to a PURL. A "maintainer" is someone who can modify a PURL. A maintainer of a PURL may modify the record for that PURL. A user who creates a PURL is automatically added as a maintainer. Three actions may be taken on a PURL: Creation, Advanced Creation or Searching. These three actions may be accessed in the PURL Web user interface as shown in Figure 3. Creating a simple or advanced PURL creates a record for that PURL on a PURL server. A simple PURL merely redirects to a given URL. An advanced PURL may return any of the HTTP response codes listed in Table 1, including the 303 response code used to return information about physical or conceptual resources. To modify or delete PURL is done from searching result.


Figure 3. Actions on PURLs

2.1 Create a New PURL

PURLs require a Domain to hold them. Domains have to be created before PURLs may be placed in them (see 5.1 Create a New Domain).

Simple PURLs are always of type 302 (see Table 1 for information on PURL types). That is, resolving a simple PURL will always return an HTTP response code of 302 (Found) with a Location header specifying where the requester should seek the requested resource. Simple PURLs are thus a handy simplification of advanced PURLs to account for a common use case. Simple PURLs may be created via the PURL Creation Form. Figure 4 shows the creation of an example simple PURL. A target URL is the URL to which the PURL will redirect. A maintainer is a user or group authorized to administer a PURL. A user who creates a PURL is automatically added as a maintainer. In this case, a PURL will be created on a PURL server with the path "/zepheira/examples/BBC". If the PURL server was running on a machine called purlz.org, then the resolution of http://purlz.org/zepheira/examples/BBC would result in an HTTP 302 response directing the user (or Web browser, or other computer application) to look for the desired resource at http://bbc.co.uk/, the British Broadcasting Service's Web site. Three maintainers are listed for this PURL; the users "testuser" and the group "testgroup".


Figure 4. Creating a PURL

2.2 Create an Advanced PURL

PURLs require a Domain to hold them. Domains have to be created before PURLs may replaced in them (see 5.1 Create a New Domain).

Advanced PURLs may be created via the PURL Advanced Creation Form. Note that this form will adjust itself to gather the information required for the type of PURL that you select. Since simple (302) PURLs were covered in 2.1 Create a New PURL, the example given below illustrates a PURL of type 303.

Advanced PURLs may return any HTTP response code listed in Table 1. Of those, PURLs of types 302 (simple redirections) and 303 (information about non-informational resources) are the most common. Figure 5 shows the PURL type being selected in the Web user interface. The first six types are the entries from Table 1, as previously discussed. The last three (Clone, Chain or Partial-redirect) are special actions that require some additional information but eventually result in a PURL of one of the six types listed in Table 1. Cloning a PURL allows one to create a new PURL based on the record of an existing PURL. Chaining allows a PURL of type 302 to refer to another PURL (of any type) without the network overhead of a separate redirection.


Figure 5. Selecting the Type of an Advanced PURL


Partial-redirect PURLs allow PURLs of type 302 to be created which refer to a directory level portion of a URL; any path information appended to a partial redirect PURL is in turn appended to its target URL. That allows a single PURL to redirect to a hierarchy on a target Web server.


Figure 6. Partial-redirect


There are four (4) types of partial-redirect PURLs: Partial, Partial-append-extension, Partial-ignore-extension and Partial-replace-extension. The plain Partial is simplest. Any string added to the end of a Partial PURL is appended to its target prior to redirection. For example, suppose we have a PURL with an id of 'http://[URL]/net/partialexample/' that redirects to a target of 'http://example.com/partialtest/'. If we then try to resolve the URL 'http://[URL]/net/partialexample/foo/bar/baz' we will find that an HTTP 302 message is returned that redirects us to the location 'http://example.com/partialtest/foo/bar/baz'. The "extra" path information added the end of the Partial PURL was added to the end of the target URL. Partial PURLs are treated as simple strings of characters, so any attempt to resolve a URL with a Query String on the end will also get appended verbatim to the target, like so: 'http://[URL]/net/partialexample/foo?bar=baz' will be redirected to 'http://example.com/partialtest/foo?bar=baz'.

A Partial-append-extension PURL is a type of partial-redirect a PURL that allows a file extension to be appended to the target URL at the time of the PURL's resolution. This is occasionally useful when creating partial-redirects to target systems that use file extensions to separate content types. The file extension to append to the target is given immediately after the PURL id. For example, consider a PURL of type partial-append-extension called 'http://[URL]/net/partialappendextension/' that has a target of 'http://example.com/partialappendtest/'. If you resolve the partial with some added path, say 'http://[URL]/net/partialappendextension/foo/bar/bam?id=fizzle', it will redirect to 'http://example.com/partialappendtest/bar/bam.foo?id=fizzle'. The file extension 'foo' is added to the PURL immediately after the PURL id and immediately before any additional path information. The file extension ('foo') is then stripped from the path and added to the end of the target URL after the path extension but before any Query String. Any Query String is appended to the end of the newly created target URL.


Figure 7. Partial-append-extension


A Partial-ignore-extension PURL is a type of partial-redirect PURL that removes any file extensions from the path information used to create the target URL. For example, a PURL 'http://[URL]/net/partialignoreextension/' with a target of 'http://example.com/partialignoretest/' when called as 'http://[URL]/net/partialignoreextension/foo.html' would redirect to 'http://example.com/partialignoretest/foo'.


Figure 8. Partial-ignore-extension


A Partial-replace-extension PURL is a type of partial-redirect PURL combines the functionality of the Partial-append-extension PURL and Partial-ignore-extension types. It ignores any file extension given in the PURL and appends a file extension provided in the PURL path. For example, a PURL called 'http://[URL]/record/' and a target of 'http://example.com/records/' when called as 'http://[URL]/record/htm/foo/bar.html' would redirect to a target of 'http://example.com/records/foo/bar.htm'.


Figure 9. Partial-replace-extension


Figure 10 shows the creation of an example advanced PURL. The PURL path shown is meant to suggest the form of deep hierarchy often found in real-world data. The example PURL is of type 303 (labeled in the pulldown menu as "See also URLs", which are used for resources which may not be directly accessible on the World Wide Web. Two maintainers are listed; a maintainer is a user or group authorized to administer a PURL. Finally, the "See also URL" itself is provided, which gives information about the addressed resource without it actually pretending to be the addressed resource, as would a response to a 301, 302 or 307 PURL.


Figure 10. Creating an Advanced PURL

2.3 Search for PURL Information

PURL records may be searched using the PURL Search Form, an example of which is shown in Figure 11. Records may be searched by PURL path (see Figure 1 for the definition of a PURL path), target URL, See Also URL or maintainer IDs. A target URL is a URL that a PURL of type 301, 302 or 307 redirects to (see the list of PURL types in 1. Overview of PURLs). A See Also URL is a URL that a PURL of type 303 refers to. A maintainer is a user or group authorized to administer a PURL. Two types of maintainer fields are used: "Maintainer IDs" expands groups into lists of users and "Explicit Maintainers" does not. Figure 11 shows a sample search for PURLs maintained by the user "testuser". Disabled PURL records may be searched by selecting the checkbox labeled "Search disabled PURLs" in the PURL Search Form as shown in Figure 11. PURL records become tombstoned if they are deleted via the PURL Deletion Form.


Figure 11. Searching for PURLs

2.4 Modify an Existing PURL

Records for existing PURLs may be modified by selecting "Modify" button (Figure. 11) in search results table (2.3 Search for PURL Information), which is much like the form for creating a new PURL (Figure. 12).


Figure 12. Modifying a PURLs

2.5 Disable an Existing PURL or Enable an disabled PURL

The status of records, which is enabled or disabled, for existing PURLs is changed by selecting "Change" button (Figure. 11) in search results table (2.3 Search for PURL Information), which is much like the form for creating a new PURL (Figure. 13).


Figure 13. Change status for PURLs

2.6 Search for PURL's History

Information regarding the changes to a PURL may be found using results from the PURL Search Form. Clicking on "History" button in search results table (2.3 Search for PURL Information) will display history table.


Figure 14. Change history table of PURLs

3. Administering Users

Two actions may be taken on a user: Registration or Searching. These two actions may be accessed in the PURL Web user interface as shown in Figure 15.


Figure 15. Actions on Users

3.1 Register a New User

Users have to be registered with a PURL server before they will be allowed to create or otherwise administer PURLs, participate in groups or administer domains. Figure 16 shows an example user in the act of registration. "Full name", "E-mail", "User ID" and "Password" must be required.


Figure 16. Creating a PURL
After Administrator user approve your user registration,you can use registrated user account.

3.2 Search for User Information

User records may be searched using the User Search Form which is shown in Figure 17.


Figure 17. Searching User Records

3.3 Modify an Existing User

Records for existing users may be modified by selecting "Modify" button (Figure. 17) in search results table (3.2 Search for User Information), which is much like the form for creating a new user (Figure. 18). You can not modify the other user account.


Figure 18. Modifying a user

3.4 Disable an Existing User

You can invalidate your self account. Your account is changed by "Change" button (Figure. 17) in search results table (3.2 Search for User Information). To enable invalidated account can be enabled by using administrator account.


Figure 19. Invalidate account

3.5 Search for user's History

Information regarding the changes to a user may be found using results from the User Search Form. Clicking on "History" button in search results table (3.2 Search for User Information) will display history table.


Figure 20. Change history table of users

4. Administering Groups of Users

It can be convenient to create groups of users to facilitate administration. For example, if you create a large number of PURLs and each PURL may be changed by the same list of people, it will be easier to create a single group to represent those people than to individually list all people as maintainers. A user who creates a group is automatically added as a maintainer. Two actions may be taken on a group: Creation or Searching. These four actions may be accessed in the PURL Web user interface as shown in Figure 21.


Figure 21. Actions on Groups

4.1 Create a New Group

Groups may be created via the Group Creation Form. Figure 22 shows the creation of a sample group. A maintainer is a user or group authorized to administer a group and a member is a user or group that is a member of this group.


Figure 22. Creating a group

4.2 Search for Group Information

Group records may be searched using the Group Search Form, an example of which is shown in Figure 23. Records may be searched by group name, group ID, maintainer ID or member ID. A maintainer is a user or group authorized to administer a group and a member is a user or group that is a member of the group.


Figure 23. Searching Group Records

4.3 Modify an Existing Group

Records for existing groups may be modified by selecting "Modify" button (Figure. 23) in search results table (4.2 Search for Group Information), which is much like the form for creating a new user (Figure. 24).


Figure 24. Modifying a group

4.4 Disable an Existing Group

The status of records, which is enabled or disabled, for existing groups is changed by selecting "Change" button (Figure. 23) in search results table (4.2 Search for Group Information), which is much like the form for creating a new group (Figure. 25).


Figure 25. Change status for groups

4.5 Search for group's History

Information regarding the changes to a user may be found using results from the Group Search Form. Clicking on "History" button in search results table (4.2 Search for Group Information) will display history table.


Figure 26. Change history table of groups

5. Administering PURL Domains

PURLs are created within domains. A domain is the path portion of the PURL URL form, as shown in Figure 1. PURLs may not be created unless they are within a domain. A "maintainer" is someone who can modify a domain. A maintainer of a domain may modify the record for that domain. A "writer" is someone who may create a new PURL under a domain. A user who creates a domain is automatically added as a maintainer. Two actions may be taken on a domain: Creation or Searching. These two actions may be accessed in the PURL Web user interface as shown in Figure 27.


Figure 27. Actions on Domains
Creating a domain creates a record for that domain on a PURL server. Note that the creation of top-level domains generally requires permission from a PURL server administrator and may not complete immediately. Modification allows the domain record to be updated. Domain records may be searched by the general public. Finally, domain records may be disabled. These actions are described in detail below.

Create a New Domain

Domains have to be created before PURLs may be placed in them. Domains may be created via the Domain Creation Form. Figure 28 shows the creation of a sample domain. A maintainer is a user or group authorized to administer a domain and a writer is a user or group authorized to create PURLs within a domain.


Figure 28. Creating a domain

5.2 Search for Domain Information

Domain records may be searched using the Domain Search Form, an example of which is shown in Figure 29. Records may be searched by group name, group ID, maintainer ID or member ID. A maintainer is a user or group authorized to administer a group and a member is a user or group that is a member of the group.


Figure 29. Searching Group Records

5.3 Modify an Existing Domain

Records for existing domains may be modified by selecting "Modify" button (Figure. 29) in search results table (5.2 Search for Domain Information), which is much like the form for creating a new user (Figure. 30).


Figure 30. Modifying a domain

5.4 Disable an Existing Domain

The status of records, which is enabled or disabled, for existing domains is changed by selecting "Change" button (Figure. 29) in search results table (5.2 Search for Domain Information), which is much like the form for creating a new domain (Figure. 31).


Figure 31. Change status for domains

5.5 Search for domain's History

Information regarding the changes to a user may be found using results from the Domain Search Form. Clicking on "History" button in search results table (5.2 Search for Domain Information) will display history table.


Figure 32. Change history table of domains

Choose to approve or deny each request
You need to be logged in as an admin to perform this action.