Design Principles. The Committee recognizes the complexity and fragmented nature of our nation’s ever-changing health care system. To the extent practical, the Committee will seek to implement each Plan in a manner consistent with the guidelines set out below, subject to both the financial requirements of such Plan and its Purpose.
Design Principles. In exercising its authority under this Section 10.2, the Committee shall adhere to the design principles described in Exhibit G. A Plan only may provide Benefits as defined in Section 1.3.
Design Principles. 10.4.1 The Parties must comply with the following design principles during the Detailed Site Design process:
Design Principles. 3.1.1. In order to avoid adversely affecting historic properties, [insert name of installation] shall ensure that Rest Easy conforms to the Secretary of the Interior’s Standards for Rehabilitation, Design Guidelines for Department of Defense Historic Buildings and Districts and the DOD Rehabilitation Treatment Measures. (Appendix D) (Treatment Standards) during the term of the Ground Lease.
Design Principles. Use the existing design pattern library to implement a modern, world-class, and timeless look and feel that is not based on current and quickly-outmoded trends. Provides an experience comparable to best-in-class consumer web products, with a beautiful interface and seamless functions. Is easy-to-use for people who may have low literacy and tech familiarity. Makes a complicated and confusing process easy to complete. Uses friendly, clear language in descriptions, instructions, field names, etc. that can be understood by people reading at a third-grade level, avoiding government and technical lingo. Is responsive (mobile-centric), providing a great experience on both desktop and mobile devices, and functional on older versions of common browsers. Is accessible: Must meet Gov Sec 508 and WCAG 2.0 guidelines; Incorporates Mayor’s Office on Disability and Mayor’s Disability Council recommendations. Is multilingual: Must take into account all pages and forms will be machine or human translated into San Francisco’s official languages: English, Spanish, Chinese, Filipino (human translations will be performed by a separate City vendor; implementation will be part of this project).
Design Principles. PPR and PBOT will lead and be responsible for preparation of the Design Principles, which will guide the further design and engineering of the North Green Loop (to be constructed by one or more future private developers). The Design Principles will address and include: general design parameters that ensure that the Green Loop looks and functions as a coherent single element across the USPS Property and is consistent with applicable guiding documents; construction guidelines that require uninterrupted public street and park access during North Green Loop construction; and operations and maintenance parameters that describe an ownership construct for the North Green Loop that protects public resources while facilitating successful asset management and site activation, and which may include resources such as revenue from the existing parking garage and/or revenue from parking built in excess of programmatic ratios. PPR and PBOT will ensure they obtain feedback from Prosper Portland so that the Design Principles result in viable development scenarios for the North Green Loop Lots, including feasible integration of the North Green Loop (through elevated plazas and skybridges accessible from adjacent structures) with the improvements private developer(s) will construct on the North Green Loop Lots.
Design Principles. The questionnaire has either been implemented as an online or offline questionnaire (see 1.2). The online questionnaires make use of immediate plausibility and completeness checks. The offline questionnaires rely on trained and experienced interview personnel. In all implementations several types of questions are included: • Single Choice Selection (‘single’, used in 10 questions in the national survey): The participant has to decide within a list of alternatives. In some questions an openly defined alternative is included (for example ‘Other’). • Multiple Choice Selection (‘multiple’ used in 7 questions): The participant has to pick one or more items from list of alternatives. Some questions may include a fixed unspecific choice (for example ‘Other’). The order of the alternatives in longer lists is determined at random to avoid any bias introduced by the positioning in the list. • Number (‘number’ used in 9 questions) The participant has to provide a number (for example ‘Age’). • Yes/No Selection (‘yes’/’no’ used in one question): The participant has to agree or disagree to a number of suggestions. • Type-3 or Type-5 Scale (‘type-3’ used in one question, ‘type-5’ used in 40 questions): A list of alternatives which have to be evaluated using a scale of three or five (for example ‘always’ to ‘never’ or ‘much more’ to ‘much less’). The participant has to make a decision, but has also the opportunity to choose a middle position (i.e. ‘occasionally’ or ‘no change’). The order of the alternatives in longer lists is determined at random to avoid any bias introduced by the positioning in the list. • Type-3 or Type-5 Scale with back-out option (‘type-3-bo’ used in 5 questions, ‘type-5-bo’ used in 3 questions): A type-3 or type-5 scale with an extra back-out option like, for example, ‘cannot judge’. • Type-6 Scale (‘type-6’ used in one question): A list of alternatives which have to be evaluated using a scale of six (i.e. ‘very negative’ to ‘very positive’). The participant has to make a decision. There is no middle position. The order of the alternatives in longer lists is determined at random to avoid any bias introduced by the positioning in the list. • Type-6 Scale with back-out option (‘type-6-bo’ used in one question): A type-6 scale with an extra back-out option like, for example, ‘cannot judge’. • Continuous Scale Type 1 (‘cont-T1’ used in one question): A list of alternatives which have to be evaluated using a continuous scale implemented in an online que...
Design Principles. This section presents a brief analysis of the most crucial factors and decisions leading to the design that will be presented at the sub-sequent sections. An overview of the requirements and constraints of the architectural elements of the platform is documented in D1.2 [1] and D1.3 [2]. The architectural design is based on the principles of Service Oriented Architecture (SOA). SOA provides an approach for creating service-based architectures, where each service carries out a small, well-defined set of functionality, reusable and independent. One can individually use these (reusable) services or bind them in larger aggregated (specific) ones with a process called orchestration. This approach provides a great amount of flexibility, reusability and loose coupling of applications. In the case of the project, where several functions are provided as services (e.g. supervision and analytics services), SOA provides a suitable approach. Furthermore, the design uses the specification described in IEC 61968 “Application integration at electric utilities - System interfaces for distribution management” [4] as a guideline for integration of legacy systems of the DSO. The standard is intended to support the inter-application integration of a utility enterprise that needs to connect disparate applications that are already built or new (legacy or purchased applications) each supported by dissimilar runtime environments. IEC 61968, which is part of the Common Information Model (CIM) [5] standards series, supports exchange of applications’ data on an event driven basis and implemented with middleware services (Message Brokers, Message Oriented Middleware - MOM, Message- Queuing Middleware, and Enterprise Service Buses-ESB). The design is based on the use of an ESB as a middleware. In the example presented in Figure 1, interface adapters are used as a means to integrate many of the legacy systems with other application systems that are IEC 61968 (or CIM) compliant. Information are published through middleware services (in the standard format) enabling multiple “listeners” and better monitoring of the underlying processes. The CIM is an implementation agnostic model, defining information used by electric utilities in UML as classes along with the relationships between these classes. The exchange of information in CIM is implemented through RDF (Resource Description Framework) models stored in a standard format, for example, XML (eXtensible Markup Language). Some sample class...
Design Principles. The ESB acts as a standards-based distributed integration platform, combining various types of messaging paradigms, transformation, routing and web services. The initial intention is to support REST (REpresentational State Transfer) as well as implementation of the Remote Procedure Call (RPC) i.e. Simple Object Access Protocol (SOAP). REST is an architectural style that defines a set of constraints to be used for creating web services commonly used in the development of Web services. Web Services that conform to the REST architectural style, (RESTful web services) allow the requestor to access and manipulate textual representations of web resources by using a uniform and predefined set of stateless operations. This allows a decoupled architecture and lightweight communications between communicating parties. SOAP is a messaging protocol specification allowing different systems to communicate, typically using Hypertext Transfer Protocol (HTTP) and the Extensible Markup Language (XML). Commonly regarded as the protocol of the choice for inter-application and business-to-business communications, many ESBs in the past were based on combination of SOAP/XML for information exchange. Aiming to achieve interoperability both with legacy systems as well as the future services implementation, both technologies shall be supported. Toward this scope, functionalities of legacy applications will be “wrapped” as services if necessary. As already mentioned, the ESB will follow the specification described in IEC 61968. Each flow related to data exchange from/to the ESB with the legacy systems shall be in a CIM compliant data format. In the occasion where the system communicating with the ESB does not support the format, an adapter will be responsible for translating it. Figure 5 Scope of IEC 61968-100 [7] Furthermore, “Part 100: Implementation profiles” [7] of the standard’s series, specifies an implementation profile for the application of the other parts of IEC 61968 using common integration technologies, including Java Message Service (JMS) and web services. This standard also provides guidance with respect to the use of Enterprise Service Bus (ESB) technologies. As presented in Figure 5, the integration layer, enables different technologies between receiver and transmitter, as well as provides support for one-to-many information exchanges (publish/subscribe integration patterns) and key functionality such as delivery guarantees. Java Message Service is an API for message...
Design Principles. The data managed by the DAP have certain characteristics that could characterize them as “big data” [15]. The 3Vs (volume, variety and velocity) are three defining properties or dimensions of big data, with volume referring to the size of data, variety referring to the number of types of data and velocity referring to the speed of data processing. On one hand we have a large volume of data to be stored and a variety of types (e.g. CIM network models, grid measurements), acquired from different systems (e.g. SCADA MDMS, GIS). On top of that, we have a data ingestion that could be considered near real-time for some types of data (e.g. from SCADA). Furthermore, as already mentioned, the creation of such a platform dictates flexibility and scalability both in capacity as well as in processing power. CIM-based network models have generally been managed in relational databases (RDBMS) and queried through complex Structured Query Language (SQL). Unfortunately, such data models are difficult to naturally represent in relational structures creating a management overhead. The object-class hierarchy of the network model is decomposed into numerous linked relational tables and sophisticated queries must be developed using large numbers of table joins. The use of a triple-store [16] or graph [17] database technology facilitates [18] the management of the data representation of such models, in its native triple format (subject-predicate-object). SPARQL [19], an RDF query language, enables retrieval and manipulation of data stored in triples. The solid benefits of traditional relational databases include efficient storage/transactions and retrieval, guarantee of validity of data and concurrent access (ACID properties), as well as data security. But on the other hand, Distributed File Systems (or network file systems), such as the Hadoop Distributed File System (HDFS) [20], enable multiple users using different machines to share file storage and computational resources and provide performance scalability and resilience. Non-relational databases, such as HBase [21] - a distributed key-value store on top Hadoop- provide flexibility in terms of data schemas and scalability. Based on the above, as well as considering the visualization requirements of DAP, its design will be based on the following tools/libraries:
