| A Project of OCLC Research | OCLC Online Computer Library Center |
PURL |
 |
1.0 General Questions (Terminology and Philosophy)
1.1 What does PURL stand for?
1.2 What is a PURL?
1.3 What does a PURL do?
1.4 What does a PURL look like?
1.5 Why do we need PURLs?
1.6 What makes PURLs "persistent"?
1.7 What is a PURL resolver?
1.8 What is a domain?
1.9 What is a partial redirect or partial redirection?
1.10 What is the difference between a PURL, a domain, and a partial redirect?
2.0 Questions about Registering with a PURL Resolver
2.1 Who are registered users?
2.2 Should I become a registered user?
2.3 What can I do (or not do) as an unregistered user?
2.4 What can I do as a registered user?
2.5 How do I become a registered user?
3.0 Questions about Creating PURLs, Domains, and Partial Redirects
3.1 Can I create a PURL?
3.2 How do I create a PURL?
3.3 How is the name component of a PURL assigned?
3.4 How do I know if the PURL name I assign is unique?
3.5 What is the relationship between the name in a PURL and the URL associated with it?
3.6 Can I create a top-level domain?
3.7 How do I request the creation of a top-level domain?
3.8 Can I create a subdomain?
3.9 How do I create a subdomain?
3.10 Can a PURL and a domain have the same name?
3.11 Can I create a partial redirect?
3.12 How do I create a partial redirect?
3.13 What is the syntax of the name component of a PURL, domain, or partial redirect?
3.14 Can I delete a PURL?
3.15 Can I delete a domain?
3.16 Can I delete a partial redirect?
4.0 Questions about Access to PURLs
4.1 What is an access control list?
4.2 What is a group?
4.3 What are groups used for?
4.4 Who are group members?
4.5 Can I create a group?
4.6 How do I create a group?
4.7 How do I become a member of a group?
4.8 What can I do as a member of a group?
4.9 How do I designate members of my groups?
4.10 Who are the maintainers of a PURL, domain, or partial redirect?
4.11 How do I become a maintainer of a PURL, domain, or partial redirect?
4.12 What can I do as a maintainer of a PURL, domain, or partial redirect?
4.13 How do I designate the maintainers of my PURLs, domains, and partial redirects?
4.14 Who are the readers of a PURL, domain, or partial redirect?
4.15 How do I designate the readers of my PURLs, domains, and partial redirects?
4.16 Who are the writers of a PURL, domain, or partial redirect?
4.17 How do I designate the writers of my domains?
4.18 How do I become a reader or writer of a PURL, domain, or partial redirect?
4.19 What is a universally resolvable PURL, domain, or partial redirect?
4.20 What is a privately resolvable PURL, domain, or partial redirect?
4.21 How can I make a PURL, domain, or partial redirect universally or privately resolvable?
5.0 Questions about Using PURLs
5.1 What can I do with a PURL?
5.2 What sorts of objects should be assigned PURLs?
5.3 What sorts of objects should be assigned partial redirects?
5.4 Will OCLC be the gateway to my collection?
5.5 How can I tell whose PURL service resolves a specific PURL?
5.6 How can I save PURLs as bookmarks?
5.7 Can I use local references in conjunction with a PURL? (i.e., http://purl.foo.com/ME/HOME#LREF)
5.8 What happens to relative HREFs in documents retrieved via PURLs?
6.0 Questions about Maintaining PURLs
6.1 Are PURLs updated automatically when their associated URL changes?
6.2 Who keeps PURLs up-to-date with their associated URLs?
6.3 How do I update or maintain a PURL?
6.4 Who can modify a PURL's associated URL?
6.5 Does a PURL ever have more than one associated URL at a time?
6.6 Does a PURL have the same associated URL forever?
6.7 Is it possible for a given URL to be assigned multiple PURLs?
7.0 Questions about the Design of the PURL Service
7.1 Can PURLs fail?
7.2 Is this a proprietary or an open solution?
7.3 What is the relationship between PURLs and Uniform Resource Names (URNs)
7.4 Does a PURL server have to use redirection?
7.5 If PURLs are widely used, won't PURL servers become hopelessly overloaded?
7.6 Do PURLs impose additional network burdens or performance problems?
8.0 Questions about Running a PURL Service
8.1 How can I get the OCLC PURL software?
8.2 How do I install and run the OCLC PURL software
8.3 Can I build my own PURL server?
8.4 Where can I find the PURL software source code?
8.5 What platforms does the PURL resolver run on?
8.6 How do I build my own PURL server from the source code?
9.0 Further Information
PURL stands for "Persistent Uniform Resource Locator."
Functionally, a PURL is a URL.
Instead of pointing directly to the location of an Internet resource, a PURL points to an intermediate resolution service. The resolution service associates the PURL with the actual URL and returns that URL to the client, which can then complete the transaction in the normal fashion.
In Web parlance, this is a standard HTTP "redirect."
_______ PURL ----------
| | ------------>> | | Resolver associates PURL with
| | | PURL | unique URL; maintenance utilities
| C | URL | SERVER | facilitate creation of PURLs and
| L | <<------------ | | modification of associated URLs.
| I | ----------
| E | URL ----------
| N | ------------>> | |
| T | | RESOURCE |
| | Resource | SERVER |
| | <<------------ | |
-------- ----------
PURLs look just like URLs because they are URLs. A PURL has three parts: (1) the protocol, (2) the resolver address, and (3) a name.
Here are a few examples of PURLs (some are hypothetical):
http://purl.oclc.org/OCLC/RSPD
---- ------------- ---------
/ | \
protocol resolver address name
http://purl.oclc.org/oclc/rsch/metadataII
---- ------------- --------------------
/ | \
protocol resolver address name
http://purl.somewhere.edu/library/catalog
---- ------------------ ---------------
/ | \
protocol resolver address name
http://purl.org/keith/home
---- -------- ----------
/ | \
protocol resolver address name
http://purl.org/net/weibel
---- -------- ----------
/ | \
protocol resolver address name
http://purl.publisher.com/journal/article_id
---- ------------------ ------------------
/ | \
protocol resolver address name
Here's a PURL taken from a record in the InterCat Catalog:
http://purl.oclc.org/oclc/oluc/32127398/1
---- ------------- --------------------
/ | \
protocol resolver address name
Sometimes URLs do not work because Internet resources move, change names or method of access, or other reasons. Once a URL fails, all instances of that URL (for example, links in a Web document or a bibliographic record) become invalid.
They never change.
A PURL can be associated with any given resource/URL. While PURLs allow you to associate different URLs with them, the PURL itself never changes. Put another way, you can change what a PURL resolves to, but you can't change the PURL.
This means that a PURL can last longer than any particular URL that may be associated with it. PURLs persist indefinitely, and as long as they do, all instances of such PURLs (for example, links in a Web document or a bibliographic record) remain valid.
Of course, someone has to operate the PURL resolvers that provide this persistence, and that's the second source of persistence for PURLs. OCLC has long been committed to facilitating access to the world's information, and that commitment stands behind PURLs, too. We encourage others who decide to operate PURL resolvers to provide the same level of commitment so the PURLs they resolve are truly persistent.
A PURL resolver is a service, available via standard HTTP 1.0 protocols, that facilitates the creation, maintenance, and resolution of PURLs.
Domains are subdivisions of the name space on a PURL resolver. They are very much like directories in a file system. The current implementation provides the ability to control who has write access (i.e., the ability to create PURLs, subdomains, etc.) within a domain. In the future, read access control will also be provided but for now, anybody can read (i.e., resolve) anybody else's PURLs.
There are two varieties of domains: top-level and subdomains.
The concept of partial redirection is the use of a domain as a prefix for a localized hierarchy of URLs. This is possible because a PURL resolver will resolve as much of a PURL as it can find in its database and append the remainder (unresolved portion) to the end of the resolved URL. For example, if the partial redirect http://purl.foo.com/bar exists and is associated with the URL http://your.web.server/your/servers/web/root then an attempt to resolve the partial redirect PURL http://purl.foo.com/bar/some/other/stuff.html will resolve to the URL http://your.web.server/your/servers/web/root/some/other/stuff.html
Using this concept, you could create a partial redirect as the permanent name prefix for all the resources stored at a web site or any hierarchical subset thereof. For example, suppose you created the partial redirect described above. Every document stored under your server's web root directory could then be accessed by appending its relative (i.e. partial) path to the partial redirect. This would allow your site's users to use the partial redirect as the prefix for all documents at your site and allow you to relocate your entire web and change only the single partial redirect you created without your users needing to know anything about it.
A partial redirect is a special-purpose PURL that acts like a domain. A regular domain has no associated URL. While a partial redirect has a URL associated with it, that URL is not guaranteed (or even expected) to reference an actual resource. The URL associated with a partial redirect may only be a prefix common to the complete URLs of multiple resources. In contrast, the URL associated with a PURL is expected to reference a single actual resource.
Registered users of a PURL resolver are people who have created a user ID and password on the PURL resolver.
If you want to be able to do any of these things, you must become a registered user. Otherwise, you do not have to become a registered user.
Unregistered users can resolve and search a resolver for only universally-resolvable PURLs, domains, and partial redirects. They can not do these things.
As a registered user, you can:
Point your Web browser to a PURL resolver, for example, OCLC's PURL resolver, and follow the resolver's instructions for becoming a registered user. The resolver should provide you with a form on which to enter a user ID and a password. Once you have received confirmation that your user ID and password have been accepted, you are a registered user of that PURL resolver.
Yes. Anyone can create a PURL.
If you are not a registered user of the PURL resolver on which you want to create a PURL, you must become one. You are then able to create PURLs in domains of which you are a writer.
To create a PURL, point your Web browser to a PURL resolver, for example, OCLC's PURL resolver, and follow the resolver's instructions for creating a PURL. PURL resolvers provide a form for you to fill out to create a PURL. (This form should provide you with a default public domain in which you are allowed to create PURLs, so you don't have to go fishing for one.)
As the creator of a PURL, you assign the name component of the PURL. Names can be fairly arbitrary (see examples, above). For example, the name oclc/rsch/metadataII can be read as "the resource metadataII in the subdomain rsch in the top-level domain oclc."
As registered user, you can create a name provided:
The PURL resolver will not allow you to create a PURL if an identical PURL already exists. You can also search the resolver's database for the PURL you have in mind before you try to create it.
None.
A PURL can look very different from its associated URL. For example, suppose the URL for a resource is
http://my.address.org/very/long/path/name/and/obscure/file_name.txt
This URL can be associated with the PURL
http://purl.oclc.org/foo/bar
It is not necessary for the PURL name component to duplicate any portion of the associated URL.
Not directly. You can request the creation of a top-level domain by the administrator of a PURL resolver but there is no guarantee that your request will be granted. Each site running a PURL resolver may establish their own policy for allocating top-level domains.
There are no functions of a PURL resolver that require ownership of a top-level domain, so there is nothing you can do with a top-level domain that you can't do with a subdomain.
If you are not a registered user of the PURL resolver on which you want to define a top-level domain, you must become one. You can then request the creation of a top-level domain on the resolver by the resolver's administrator.
As the owner of a top-level domain or a subdomain, you have full administrative control over its accessibility, including the ability to define other readers, writers, and maintainers.
To request the creation of a top-level domain, point your Web browser to a PURL resolver, for example, OCLC's PURL resolver, and follow the resolver's instructions for creating a top-level domain. PURL resolvers provide a form for you to fill out to request a top-level domain. Submit the form and the resolver's administrator should notify you when your request has been granted or denied.
Yes. Anyone can create a subdomain.
If you are not a registered user of the PURL resolver on which you want to create a subdomain, you must become one. You are then able to create subdomains in domains of which you are a writer.
To create a subdomain explicitly, point your Web browser to a PURL resolver, for example, OCLC's PURL resolver, and follow the resolver's instructions for creating a subdomain. The PURL resolver should tell you immediately whether or not your subdomain was created successfully.
To create a subdomain implicitly, create a PURL which has a nonexistent subdomain in its name. If you are a writer of the last existing domain in the PURL's name, then the subsequent nonexistent subdomains will be created automatically during the creation of the full PURL name you requested.
Yes. This may be confusing at first, but it is an important feature to grasp. The best way to demonstrate is by example. Consider the following PURLs, each of which has a URL associated with it in the resolver:
http://purl.foo.com/net/jdoehttp://purl.foo.com/net/jdoe/barThe first PURL's name, net/jdoe, is also the name of the domain in which the second PURL's name exists. This aspect of PURL naming differs from the common rule in file systems that does not allow a file and a directory to share a name.
Yes. Anyone can create a partial redirect.
If you are not a registered user of the PURL resolver on which you want to create a partial redirect, you must become one. You are then able to create partial redirects in domains of which you are a writer.
To create a partial redirect, point your Web browser to a PURL resolver, for example, OCLC's PURL resolver, and follow the resolver's instructions for creating a partial redirect. The PURL resolver should inform you of the success of your request immediately.
The name component of a PURL, domain, or partial redirect uses the URL syntax with several exceptions:
In short, only the following characters are allowed in the name component of a PURL, domain, or partial redirect:
a-z lower-case Roman alphabeticA-Z upper-case Roman alphabetic0-9 digits^ caret% percent sign/ slash$ dollar sign_ underscore. period+ plus sign! exclamation point* asterisk' apostrophe( left parenthesis) right parenthesis; semicolon@ commercial at& ampersand= equal sign, comma- hyphenNo. No one can or should delete a PURL. A PURL can, however, be associated with a "null URL", i.e., no URL at all, in which case, a history page is returned when the PURL is resolved.
No. Once a domain is created it will persist indefinitely.
No. No one can or should delete a partial redirect. A partial redirect can, however, be associated with a "null URL", i.e., no URL at all, in which case, a history page is returned when the partial redirect is resolved.
An access control list is a list of registered users, groups, or both, that is associated with one and only one PURL, domain, or partial redirect. Access control lists are attributes of a PURL, domain, or partial redirect. There are 3 kinds of access control lists:
A group is a list of registered users, groups, or both. The group all includes all registered users. When access control is fully implemented, there will be a special group which includes all registered and unregistered users.
Groups are mechanisms that allow you to organize and easily specify lists of registered users. This mechanism is useful for specifying other readers, writers, or maintainers of things you own. In and of themselves, groups do not bestow new capabilities on their members. A group must be specified as a member of a PURL's, domain's, or partial redirect's read, write, or maintenance access control list to have any effect on its members.
Group members are registered users who are included in a group.
Yes. Anyone can create a group.
If you are not a registered user of the PURL resolver on which you want to create a group, you must become one. You are then able to create groups. You are not automatically a member of a group you have created unless you have included your own registered user ID in the group.
To create a group, point your Web browser to a PURL resolver, for example, OCLC's PURL resolver, and follow the resolver's instructions for creating a group. The PURL resolver should inform you of the success of your request immediately.
The owner of the group must include your registered user ID or the name of another group of which you are a member in the group for you to be a member.
That depends entirely on how the group is used. If it is specified as a member of an access control list of a PURL, domain, or partial redirect, then you have corresponding access privileges. If the group is not used for anything, then your privileges have not expanded as a result of being a member.
As a registered user, you can create groups and specify which registered users are members of the groups you create by specifying their registered user id's, either explicitly or by specifying other groups.
You and other users whom you designate in the maintenance access control list of the PURL, domain, or partial redirect are its maintainers. (The ability to designate other users as maintainers has not yet been implemented.)
Either by creating it yourself or by being designated in its maintenance access control list by its owner when this feature becomes available.
As a maintainer of a PURL or partial redirect, when access control is fully implemented you will be able to specify:
As a maintainer of a domain, you can now specify who can create things in it. When access control is fully implemented, you will be able to specify:
As the owner of a PURL, domain, or partial redirect you will be able, in a future release of the PURL resolver software, to specify other maintainers for it when you create or maintain the PURL, domain, or partial redirect by including them in its maintenance access control list.
You and those whom you designate in the read access control list of your PURL, domain, or partial redirect are its readers. Readers can resolve your PURL, domain, or partial redirect. Until read access control is implemented, anyone who can connect to the appropriate resolver can resolve your PURLs, domains, and partial redirects.
When read access control is implemented, each PURL, domain, and partial redirect will have a read access control list associated with it. You will be able to designate readers of each thing you own by specifying the members of its associated read access control list.
You are the only writer of the PURLs and partial redirects you have created. (Creating a PURL or partial redirect is the same as writing it and can only be done once for any PURL or partial redirect.) You and those whom you designate in the write access control list are the writers of your domains. Writers can create PURLs, subdomains, and partial redirects in a domain.
Each domain has a write access control list associated with it. You can designate the writers of each domain you own by specifying the members of its associated write access control list.
Either by creating it or by being included in its read or write access control list by its owner. Any access control list that includes the group all as a member includes every registered user on the PURL resolver as a member.
A universally resolvable PURL, domain, or partial redirect is one that anyone can get resolved or search a PURL resolver for. (With the current software, all PURLs are universally resolvable because read access control is not yet implemented.)
(This feature is not yet implemented - see universally resolvable PURLs, domains, and partial redirects. When it is implemented...) A privately resolvable PURL, domain, or partial redirect is one that will only be resolved for designated registered users of the PURL resolver on which it resides.
This feature is not yet implemented, for now all PURLs are universally resolvable by default.
You can select a PURL that you find, for example, on a Web page or in a document, and the PURL will be resolved to the associated URL, which your browser will then use to access the resource.
You can put PURLs in Web pages, documents, or other resources with the confidence that the PURL will persist over time. Your links will remain valid even if the associated URLs change. (This does not mean that a PURL magically changes its own associated URL when the referenced resource moves, you must update your PURLs when this happens.)
You can submit a PURL (or even just part of a PURL) to the PURL resolver to obtain more information about the PURL, the associated URL, or, in some cases, the resource itself.
You should assign a PURL to any discrete resource that you want users to be able to access reliably over time. For example, a home page, an electronic journal, an individual article, or a paper is a good candidate for a persistent name. Some dynamic resources such as "today's newspaper" or "closing price of Foo stock" are also good candidates.
Non-discrete resources such as sections within a document or charts or graphics that would not make sense outside the context of their containing document are not good candidates for PURLs. Temporary resources are also poor candidates.
Objects at the top of hierarchies of objects which might be moved as a unit are excellent partial redirect candidates. Depending on the underlying nature of the hierarchy, the lower-level objects may not require PURLs. For example, if the hypertext object hierarchy corresponds closely to the hierarchy of the objects in the underlying filesystem and the hypertext links are relative links based on the filesystem hierarchy, then a single PURL for the top-level object in the hierarchy is all that may be necessary.
It is our goal to have PURL servers running world wide. These PURL servers would then be gateways for the respective local organizations. Your collection can be on any PURL server of your choosing, or spread across multiple PURL servers.
It is possible for PURL servers to service more than just the local organization. For instance, the OCLC PURL server already accepts and resolves external PURLs.
Look at the resolver address in the PURL. For example, in the hypothetical PURL http://purl.foo.com/NET/jdoe, the resolver address is purl.foo.com. If the resolver address is any of the following, then the PURL is resolved by OCLC's PURL service:
Otherwise, look at the last two segments of the resolver address in the PURL. These should indicate the organizational entity running the resolver for that PURL. For example, the resolver address purl.foo.com indicates that the com(mercial) organizational entity foo runs the resolver for this PURL.
Avoid using the "save-current-document-as-a-bookmark" feature of most browsers because this will save the URL, not the PURL, of the document. Note that when you access a document via a PURL, it causes a redirect to the associated URL. The URL, not the PURL, is what the browser associates with the "current document" it is displaying. Instead, you should use your browser's manual bookmark editing features to enter PURLs by hand. That way, the PURL, not the URL associated with it, becomes the bookmark.
There's more to this question than meets the eye. Let's break it down into manageable pieces.
First, the local reference (i.e. #LREF) is a directive to the HTTP client (browser). When you select a URL containing a local reference, only the portion of the URL preceding the local reference is requested from the HTTP server. It is the client's responsibility to act on this directive in relation to the requested document once the document is received. Therefore this behavior is dependent upon the client. Not all clients handle local references the same way.
PURLs can not contain local references because we do not allow them to contain the "#" character. Since browsers would not send the local reference (i.e., anything after and including a "#" character, such as #LREF) part of a PURL to the PURL resolver, there'd be no point in allowing it.
You can use local references appended to PURLs so that your browser attempts to locate the local reference within the document retrieved by the PURL, but some browsers (incorrectly) drop the local reference upon receiving the redirect from the PURL resolver (actually any redirect from any HTTP server) and therefore fail to act on the local reference directive when the actual document is received.
As a result, PURLs with local references appended to them, such as http://purl.oclc.org/OCLC/PURL/FAQ#toc6.0, resolve to (the beginning of) the document referenced by the PURL under some Web browsers. To determine how your browser behaves, try the example PURL above. If it takes you to the top of this document, then your browser is not handling local references correctly. If it takes you to section 6.0 of this document, then your browser is handling local references correctly. Either way, you should still end up with this document.
Suppose the PURL http://purl.foo.com/DOCS/bar maps to the URL http://www.foo.com/bar/baz.html and that your browser has just retrieved this document. When an anchor (HTML <A> tag) containing an HREF attribute whose value is not a fully-qualified URL (i.e., a "relative HREF" such as <A HREF="zap/frob.html">) is selected in the browser, the browser cobbles-together a fully qualified URL to send to an HTTP server. It uses the URL, not the PURL, of the containing document up to the last "/" and appends to it the value of the HREF attribute.
For example, the anchor <A HREF="zap/frob.html"> in the document http://www.foo.com/bar/baz.html becomes the fully-qualified URL http://www.foo.com/bar/zap/frob.html sent out in a GET request from the browser. This means that the relative HREF above will not resolve to the PURL http://purl.foo.com/DOCS/zap/frob.html regardless of that PURL's existence. For this reason, do not use relative HREFs to try to reference PURLs when writing HTML documents.
Remember, relative HREFs are relative to the URL of the containing document, not the PURL it was retrieved with.
No. You (or another maintainer) must update your PURL when the associated URL changes.
It is the responsibility of a PURL's owner and its maintainers to update the PURL when the associated URL changes. You can update the URL associated with any PURL you created. In addition, you can update any PURL for which you are a maintainer.
You can perform PURL maintenance by connecting to a PURL resolver using a WWW browser and then using the PURL resolver's maintenance forms to make the appropriate changes to the desired PURL. The resolver will not allow you to modify a PURL unless you are an maintainer of the PURL.
Only maintainers can modify the URL associated with a PURL.
No. PURLs are uniquely associated with a single URL at any given moment. Over time, however, the associated URL can change. In other words, a PURL may have many URLs associated with it over time, but only one at a time.
No. The owner of a PURL can change the associated URL at will.
This is a particularly important difference between PURLs and several URN proposals. In some URN proposals, a URN is a permanent name for a unique resource and only that resource forever. Some URN proposals would allow the same resource to move, but would not allow a different resource to be associated with the URN.
Yes. This will happen when a user creates PURLs on several PURL resolvers and each of these PURLs has the same associated URL. We hope that common sense and etiquette will prevent most users from creating multiple PURLs on the same server, each of which has the same associated URL.
A PURL is only as good as its associated URL. If the associated URL becomes outdated, it will fail. However, the PURL and its full history will always be available.
The PURL resolver maintenance component is designed to facilitate the upkeep of PURLs.
PURLs are based upon widely accepted and deployed, open Internet protocols.
It is anticipated that organizations other than OCLC will run PURL servers. Libraries, government organizations, and publishers are examples of organizations that may elect to become PURL resolvers, either using tools from OCLC or developing their own.
URNs are under development under the auspices of the Internet Engineering Task Force (IETF).
The PURL work has been strongly influenced by OCLC's active participation in the IETF Uniform Resource Identifier working groups. There is nothing incompatible between PURLs and ongoing URN work. OCLC will continue to participate actively in the consensus building process concerning URNs in the IETF and will support the results of that process as it is deployed.
PURLs satisfy most of the requirements of URNs in a technology that is deployed today. This technology can be applied to the task of maintaining catalogs of Internet resources today, and can be transitioned smoothly into the URN architecture once it is deployed.
Section 6.6 relates an important difference between PURLs and several URN proposals.
No, a server can choose to return the document directly. The OCLC PURL Service uses redirection to reduce the load on the PURL resolver. Indirection, not redirection, is the key. Even if the PURL server returns the document from its own storage, the PURL of the document does not necessarily correspond to its actual location.
The PURL architecture is based on existing distributed technology: the Domain Name Service (DNS) and the HyperText Transport Protocol (HTTP). Servers can be distributed widely, run by a wide spectrum of organizations with a commitment to maintaining persistent naming schemes (Libraries, government organizations, publishers and others).
The benefits of the additional level of indirection provided by the PURL service come at the price of additional network traffic (two network round trips instead of one). This is no less true for any name resolution service that might be implemented in the future. This is is a reasonable and low-cost tradeoff for increased link reliability and decreased catalog maintenance burdens.
If possible, please download the distribution from here.
Otherwise:
In either case, please let us know if you bring-up a PURL resolver service so we can notify you of new releases and let others know about your service.
Also, please let us know about bugs, bug fixes, enhancements, and ports so we can continue to improve the software for everyone.
See the files README and INSTALL included with the OCLC PURL software distribution.
Absolutely. We expect others to build similar tools and services.
The OCLC PURL Resolver Software distribution includes the complete source code.
The PURL code has been built and tested on the following platforms (OS/CPU/compiler):
It has also been tested on:
See the files INSTALL and PORTING in the OCLC PURL Resolver Software distribution.
See also:
Contacts:
For research directions, comments, and early adoption, send mail to purl@oclc.org.
PURLs are a result of ongoing research at OCLC Online Computer Library Center, Inc. OCLC is a nonprofit computer library service and research organization whose computer network and services link more than 21,000 libraries in 63 countries and territories. Please visit the OCLC PURL Service if you want to find out more about PURLs, download the PURL code, or see PURLs in action.
