For a comprehensive report on the PORTAL-DOORS Project, please refer to A Distributed Infrastructure for Metadata about Metadata: The HDMM Architectural Style and PORTAL-DOORS System, published online 1 June 2010 in the journal Future Internet.
See also other NPDS related papers and presentations.
Abstract: The semantic web remains in the early stages of development. It has not yet achieved the goals envisioned by its founders as a pervasive web of distributed knowledge and intelligence. Success will be attained when a dynamic synergism can be created between people and a sufficient number of infrastructure systems and tools for the semantic web in analogy with those for the original web. The domain name system (DNS), web browsers, and the benefits of publishing web pages motivated many people to register domain names and publish web sites on the original web. An analogous resource label system, semantic search applications, and the benefits of collaborative semantic networks will motivate people to register resource labels and publish resource descriptions on the semantic web. The Domain Ontology Oriented Resource System (DOORS) and Problem Oriented Registry of Tags And Labels (PORTAL) are proposed as infrastructure systems for resource metadata within a paradigm that can serve as a bridge between the original web and the semantic web. The Internet Registry Information Service (IRIS) registers domain names while the Domain Name System (DNS) publishes domain addresses with mapping of names to addresses for the original web. Analogously, PORTAL registers resource labels and tags while DOORS publishes resource locations and descriptions with mapping of labels to locations for the semantic web. Beacon is proposed as a prototype PORTAL registry specific for the problem domain of biomedical computing.
Citation: Carl Taswell, 2008, IEEE Transactions on Information Technology in Biomedicine Vol 12 No 2 pages 191-204; manuscript received 31 October 2006, published online 3 August 2007.
IRIS registries and DNS directories provide the model for the architectural style that inspired the design of PORTAL registries and DOORS directories. The most essential characteristics of this architectural style can be summarized by the following principles:
Users of today's web browsers may not be familiar with the engineering of the hidden infrastructure system that enables them to navigate to any web site around the world. But it is the IRIS-DNS infrastructure system, which is responsible for registering domain names and mapping them to numerical IP addresses, that makes it possible for the user to browse the web in such an effortless manner almost always without ever typing or even seeing the numerical IP addresses.
Moreover, from the user's perspective, what is most important now is that the speed of this conversion from domain name to IP address occurs so rapidly that the user does not experience it as a hindrance or delay in browsing. Even if the particular web page itself downloads and displays slowly, usually at least the web site address is found quickly. And that happens because the small amount of metadata (domain name and IP address) moves so quickly across the internet even if the larger amount of data (web page text and media) does not. Because of this important point, the phrase Hierarchically Distributed Mobile Metadata (HDMM) is introduced (9 May 2009) here as a name for this architectural style that characterizes both IRIS-DNS and PORTAL-DOORS.
Whereas IRIS-DNS implements the HDMM architectural style for the original web, PORTAL-DOORS extends and implements this style for the semantic web and grid. Further, PORTAL-DOORS enhances the separation of concerns principle to include the additional notion of separately optimising directories for semantic services (with use of the RDF/OWL/SPARQL stack of technologies) and the registries for lexical services (with use of character string processing and only those XML technologies that do not require use of RDF triples). This separation of concerns enables the back-end use of traditional relational database stores for PORTAL registries and RDF-triple database stores for DOORS directories. Of course, hybrid stores can be used for both PORTAL and DOORS.
In accordance with the HDMM architectural style, PORTAL-DOORS has been designed to serve the semantic web and grid in a manner analogous to the way that IRIS-DNS has served the original web. The blueprint paper (see abstract) specifying the original design for PORTAL-DOORS was submitted to IEEE in 2006 by Carl Taswell, published online in 2007 at www.IEEE.org, and appeared in print in IEEE Transactions on Information Technology in Biomedicine 2008 Vol 12 No 2 pages 191-204. The figures and tables below have been adapted from the original paper and updated with revisions. Note that the original separate design of PORTAL registries and DOORS directories has been supplemented with a new bootstrapping combined design with integrated NEXUS registrars. Both can coexist together.
|Dynamic metaphor||A distributed communications network brain of nodal neurons continuously updating, exchanging, and integrating messages with "who what where" information|
|Static metaphor||A simple phonebook||A sophisticated library card catalogue|
|Registering system||IRIS registries||PORTAL registries|
|-- Entity registered||domain||resource|
|-- Identified by||unique name||unique label (URI/IRI) with optional tags|
|Publishing system||DNS directories||DOORS directories|
|-- Attributes published||address and aliases||location and descriptions|
|-- Specified by||IP number||URIs/IRIs, URLs/IRLs, RDF triples referencing OWL ontologies|
|Serves original web||Yes via mapping of character name to numeric address||Yes via mapping of character label to URL/IRL for IRIS-DNS|
|Serves semantic web||No||Yes via mapping of character label to semantic description|
|Crosslinks entities||No||Yes via mappings within DOORS descriptions to other resources|
|Crosslinks systems||No||Yes via mappings with PORTAL crossreferences to other systems|
Resource metadata is registered and published by agents for search by users in the PORTAL-DOORS server networks. Semantic services here are defined as those using the RDF/OWL/SPARQL stack of technologies, whereas lexical services are defined as those using only character string processing. Fields within data records are considered required or permitted with respect to the schemas maintained by the root servers. The figure above displays only the most important fields; for all fields, see reference model implemented with XML Schema.
Resource metadata server networks for PORTAL registering of labels and tags and DOORS publishing of locations and descriptions are analogous to domain metadata server networks for IRIS registering of names and DNS publishing of addresses. Primary PORTAL registries may be established by any individual or organization with or without any local policies governing registration of resources. Examples shown here (GeneScene, BrainWatch, ManRay) implement policies with a problem-oriented focus on their respective specialty domains. Specific criteria for registration are determined by the local schema of the PORTAL primary which must nevertheless comply with the global requirements of the PORTAL root.
Return to Page Contents
PORTAL-DOORS as a lower-level infrastructure system must be distinguished from higher-level tools and applications built on the foundation of the infrastructure. PORTAL-DOORS as a metadata management, communication, and distribution system must also be distinguished from the actual metadata that the infrastructure is designed to send, receive, and exchange throughout the system. Fundamentally, the PORTAL-DOORS System establishes an interoperable, platform-independent, application-independent, interface standard for information exchange over the internet with a design that is guided by the HDMM architectural style, specified to fulfill additional requirements to serve both the original web and semantic web as described in the PORTAL-DOORS blueprint paper, and currently partially detailed in a draft reference implementation written in XML Schema *.xsd files.
Work to complete a reference implementation must clarify not only the structural data model for metadata records, but also the functional behavioral model for the PORTAL and DOORS services in response to requests from clients. Servers and clients must also communicate over transport protocols. The PORTAL-DOORS Project maintains a vision of serving more than one transport protocol as discussed in Section VII.E. of the PORTAL-DOORS blueprint paper. Initial drafts (prior to version 0.5) assumed use of the IRIS core protocol. The current draft (version 0.5) addresses only the structural data model. The next draft (version 0.6) will re-introduce use of a specific transport protocol but replace the IRIS core protocol with an http protocol using a RESTful web services model. At present, in a bootstrapping stage of development for PORTAL-DOORS, web services do provide a more favorable environment for spreading adoption of the system. However, a fully dedicated and optimized protocol specifically for PORTAL-DOORS may ultimately prove necessary to achieve the speed and efficiency comparable to that which exists now for IRIS-DNS.
As the PORTAL-DOORS System continues to be developed and implemented, any tool, application, or web site that accesses the PORTAL-DOORS System must be distinguished from the system itself. The PORTAL-DOORS System should not be considered either a single site or repository any more than the IRIS-DNS System of domain name registries and directories could be construed to be a single site or repository. For both IRIS-DNS and PORTAL-DOORS infrastructure systems, server data stores and client tools and applications can be written in any language on any platform. Client tools are necessary for agents to edit the information maintained at an individual server data store. Client tools are also necessary for agents and users to navigate, search and query the information stored not only at a particular server but also throughout the entire network of servers. These tools include faceted browsers, keyword search utilities, and SPARQL query interfaces.
Even more complex applications can be built in which the navigation, search, and query tools may be embedded within more sophisticated applications that hide these tools from the user interface. An important example would be an application component that provides natural language answers to natural language questions in the context of the overall function of the software application. In this example, the component converts the user's natural language question to a SPARQL query submitted to the PORTAL-DOORS System, and then converts the response from the PORTAL-DOORS System to a natural language answer for presentation to the user.
Return to Page Contents
PORTAL-DOORS has been designed to be as flexible as possible with both backward and forward compatibility from Web 1.0 to Web 3.0. Given the partition with non-semantic services on the PORTAL side and semantic services (with the RDF/OWL/SPARQL stack) on the DOORS side, and also the partition with both required and permitted elements for each of PORTAL and DOORS, there are many possible scenarios for usage of the entire PORTAL-DOORS System. Some examples include:
The original PORTAL-DOORS blueprint paper discussed the following use cases:
More detailed descriptions of examples in the context of translational research include the following use cases of PORTAL-DOORS as an information-seeking support system for:
Although originally conceived and described in the context of health care and life sciences, the diversity of possible use cases for PORTAL-DOORS remains as universal as the diversity of possible use cases for IRIS-DNS.
The PORTAL-DOORS Project maintains the following goals:
Currently, development plans envision following a roadmap with these milestones:
Return to Page Contents