Frequently Asked Questions
An OpenRegistry can be used to register any kind of resource that has a web address and machine-parsable content (i.e. with a predictable structure from which metadata can be gathered), including:
- XML documents (e.g. RSS feeds);
- web services (e.g. WPS);
- XHTML documents (e.g. books at Amazon.com);
- images (e.g. jpeg's);
It is also possible to use an OpenRegistry to maintain collections of keywords, URI's, or other identifiers that are not associated with URLs.
2: Why would I use a registry based on OpenRegistry to keep track of things? Isn't a WIKI or a web page
Using a registry like OpenRegistry to keep track of resources has a number of advantages over these other approaches.
- It is easier to restrict the content;
- It is easier to add content;
- It is easier to validate new content;
- It is easier to refresh content (by just re-registering a URL);
- It can hide a tremendous amount of custom processing behind its very simple interface;
- It can be configured to automatically refresh content on a regular basis, updating content and removing links as they go stale;
- It is easier to customize the responses;
- It enables the searching of content by keyword;
- It enables the searching of content by geography;
- It enables the searching of content by date;
- It is designed for machine-to-machine access, thus enabling the viral spread of information between peer registries;
- It is self-documenting; and
- Since it is a standard, it allows developers to benefit from "plug and play" components.
OpenRegistry is substantially simpler to implement than ebXML, CKAN, or CAT 2.0, and much more powerful than UDDI. It is easy to implement and use, and encourages the viral spread of information.
OpenRegistry includes two operations designed to enable the spread of information. The list_objects operation allows OpenRegistries to periodically harvest the contents of peer registries. As part of this operation, the requesting registry must share its own URL, thereby informing its peer of how to perform a reciprocal request. The list_peers operation allows a similar reciprocal exchange of information regarding previous list_objects requests from other servers. These features allow any OpenRegistry to become aware of all other peer registries, and to replicate their content.
Use the register_object operation to add a member to an existing collection. To create a new collection, the server administrator must configure the OpenRegistry to handle the new kind of resource.
OpenRegistry does not have an "edit" function. If the resource to be edited has been updated on the network, then the submission of an "register_object" request for the updated resource should cause the registry to repopulate the metadata that it maintains about that resource. Alternatively, any implementation of OpenRegistry is free to provide extended functionality such as edits, content validation, or approvals.
OpenRegistry does not have a "delete" function. If the resource to be deleted from the OpenRegistry has been removed from the network, then the submission of an "register_object" request for that missing resource should cause an OpenRegistry to remove it from its list of resources. Alternatively, the registry administrator can remove the resource from the registry manually.
Version 1 was based on XML, and although quite similar to version 2 it was not completely compatible. Its documentation was removed from this website in order to encourage adoption of version 2. There are likely still some implementations in the wild.