## 5 Architectural Design of the PORTAL-DOORS System  
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  
\begin{table}
\begin{tabular}{l|l|l}  & IRIS-DNS System & PORTAL-DOORS System \\ \hline Dynamic metaphor & A distributed communications network brain of nodal neurons continuously updating, exchanging, and integrating messages about ‘who what where’ \\ \hline Static metaphor & A simple phonebook & A sophisticated library card catalogue \\ \hline Registering system & IRIS registries & PORTAL registries \\ – Entity registered & domain & resource \\ – Identified by & unique name & unique label with optional tags \\ \hline Publishing system & DNS directories & DOORS directories \\ – Attributes published & address and aliases & locations and descriptions \\ – Specified by & IP numbers & URIs, URLs, RDF triples referencing \\  & & OWL ontologies \\ \hline Entity identification & Hierarchical URL & Non-hierarchical URI \\ Record distribution & Hierarchical request forwarding and response caching & Hierarchical request forwarding and response caching \\ \hline Serves original web & Yes, via mapping of character name to numeric address & Yes, via mapping of character label to URL for IRIS-DNS \\ Serves semantic web & No, because IRIS-DNS does not use RDF triples & Yes, via mapping of character label to semantic description \\ \hline Crosslinks entities & No & Yes, via mappings within DOORS descriptions to other resources \\ Crosslinks systems & No & Yes, via mappings within PORTAL crossreferences to other systems \\ \hline \end{tabular}
\end{table}
Table 1: Hierarchically Distributed Mobile Metadata (HDMM) Systems with Entity Registering and Attribute Publishingweb. The fundamental exposition of the architectural design for PORTAL-DOORS was published in the original blueprint paper [1] from which Table 1 and Figures 2 and 3 have been adapted. They have been updated with the revisions published in [11, 39, 45], and further enhanced by those introduced here for multilevel metadata and other new functionalities including aliases, priorities, and metaresources. Note also that the original _separate_ design of PORTAL registries and DOORS directories [1] has been supplemented with an alternative bootstrapping _combined_ design with integrated NEXUS registrars [11]. Both can coexist together. Further, PORTAL-DOORS extends the separation of concerns principle (see Item 4 above) to include the additional notion of separately optimising directories for semantic services (with use of logical reasoning, ontologies and the RDF/OWL/SPARQL stack of technologies) and the registries for lexical services (with use of character string processing, terminologies 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, XML stores and/or hybrid stores (such as OpenLink Virtuoso virtuoso.openlinksw.com which is an open source cross platform universal server) can also be used for both PORTAL and DOORS servers and services.  
Figure 2: PORTAL-DOORS System Data Records: 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, terminologies, or those XML technologies that do not require use of RDF triples. Fields within data records are considered _required_ or _permitted_ with respect to the schemas maintained by the root servers. The figure displays only the most important fields; for all fields, see the reference model implemented with XML Schemas.