## 5 Architectural Design of the PORTAL-DOORS System
### New Multilevel Metadata Design  
Managing the mobile metadata, both conceptually and technically, with regard to a hierarchy of metalevels also serves this goal. Therefore, as a new revision and enhancement for the PORTAL-DOORS System, a multilevel metadata analysis is introduced here in Section 5.2 while the corresponding multilevel metadata structures are further detailed in Section 6.1. The analysis begins with consideration of the collection of objects relevant to the resource in varying contexts. 1. **Resource entity:** The object of interest considered by the registrant to be the resource whether concrete or abstract, online or offline, semantic or lexical, real or virtual. This _resource entity_ may be registered at a particular PORTAL registry only if it satisfies the registration requirements of that PORTAL registry. Depending upon the problem-oriented specialty domain of the PORTAL registry and its registration policies, examples may include persons, patients, investigators, authors, or organizations; online virtual entities or offline physical entities; data services, data storage tools, and data records (independent of and unrelated to any PORTAL-DOORS metadata record); analysis services and data processing tools; authored information, books, journals, papers, web sites, and web pages; and many other examples and categories within any field of interest defined by the administrators of the particular PORTAL registry. 2. **Resource record:** The database object containing information about the resource entity for the purpose of persistent storage. This _resource record_ is stored in a database at a PDS server (a PORTAL, DOORS, or NEXUS server). Note that for the same resource entity, the information stored in a resource record at a PORTAL, DOORS, or NEXUS server will be different, and may also be different within each of the networks of PORTAL, DOORS, and NEXUS servers depending on their operation as authoritative primary or non-authoritative secondary and caching servers. 3. **Resource infoset:** The memory object containing information about the resource entity for the purpose of managing, displaying, and analyzing the information about the resource entity of interest. This _resource infoset_ is assembled by the responding PDS server that gathers all of the relevant information from possibly multiple distributed records located at various different PORTAL, DOORS, and NEXUS servers. 4. **Resource representation:** The serialized object, obtained from the memory object, representing all of the information collected and assembled about the resource entity for the purpose of interoperable information exchange compliant with the PDS interface. One or more of these _resource representations_ are sent by the PDS server in response to requests from clients if the server is configured to return a response without a message envelope. 5. **Resource message:** The message object containing one or more serialized resource representations within an envelope for the purpose of interoperable information exchange compliant with the PDS interface. This _resource message_ is exchanged between different PDS servers and/or is sent by the targeted PDS server in response to requests from clients. The term _information_ is used in the list above in a general sense referring to content without implying any special connotations about a hierarchy of metadata levels. This term _information_ will continue to beused to refer to any part of the content collectively contained in all of the metadata levels independent of any discussion of data versus metadata versus meta-metadata, or of multilevel metadata. Metadata can be associated with each of the five objects listed above. The following list summarizes the metadata for each of the five objects together with the design principles that govern software implementation for the database, web service, and interoperable messaging interface schemas for the PORTAL-DOORS System. 1.