## 5 Architectural Design of the PORTAL-DOORS System
### Other New Design Features  
As part of the design philosophy, the PORTAL-DOORS Project maintains the following general goals: 1) practical utility, 2) flexible adaptability, 3) universal applicability with an approach of inclusivity rather than exclusivity, and 4) forward revisions by extension rather than restriction in order to maintain backward compatibility and adherence to the original design goals and principles. These general design principles stand in contrast with the more specific design principles that characterize the HDMM architectural style for both the IRIS-DNS System and the PORTAL-DOORS System (see Section 4). Thus, in support of these general goals, the current iteration of re-design for the PORTAL-DOORS System also introduces several other important new functional characteristics and features:  
* **Aliases:** The original design of PDS as published in [1] specified use of a URI or IRI as the globally unique identifier, called a _label_, for any resource registered in the system. The current revision reported here now allows multiple labels for any given resource and distinguishes between a single required _canonical label_ and multiple permitted _alias labels_ for the resource. All labels, whether canonical or alias, for all resources must always be globally unique throughout the system. Thus the original design requirement for uniqueness of labels has not been violated by this revision. * **Priorities:** A number of the metadata fields, such as alias labels, supporting tags, supporting labels, locations, crossreferences, secondary registries and secondary directories permit multiple instances of the field for the same given resource. The current revision of PDS now allows for priorities to be assigned to these instances so that they can be ranked in order. A _priority_ is defined to be a single-byte integer rank in the range from 0 to 255 with precedence order in natural counting order, _i.e._, first 0 and last 255. In the case of multiple instances of labels for a resource,  
Figure 4: Resource representation: entity metadata is primary or _Level 1_ metadata about the entity itself, record metadata is secondary or _Level 2_ metadata about the _Level 1_ metadata, and infoset metadata is tertiary or _Level 3_ metadata about the _Level 1_ and _Level 2_ metadata; see also Section 5.2.  
the canonical label is always identified by the assigned priority 0 with all other alias labels assigned any priority in the range from 1 to 255. * **Metaresources:** The original blueprint design [1] also specified that resources can only be registered and managed by owners of the resources. This design principle yields a system that does not allow anonymous public editing of resources which is contrary to the policies adopted by many wiki systems. However, it is possible to design an extension of the initial PORTAL-DOORS System that maintains the original principle while also enabling secondary resources to be registered and managed by individuals who are not the owners of the primary resource. These secondary resources about primary resources are called _metaresources_. The secondary metaresources are declared by specifying their entity type as a special type called _meta-entity_. Secondary metare-sources are required to maintain a reference to their targeted primary resources. This approach assures that all metaresources about the same targeted resource can refer consistently to that resource yet be managed independently of it as the primary resource and of each other as the other secondary resources. A scientific journal article as primary resource with multiple reviews as secondary metaresources constitute a simple example. All of the referees who write the secondary reviews and the authors who write the article should have control over their own resources without interference by others. * **Agents:** The original description of PDS [1] distinguished between the roles of users and owners of resources and resource metadata.