Folder structure Clause Samples

Folder structure. The CeRTNA ERDS County Administration module provides the ability to configure a base folder structure that will be used for retrieving payloads from the CeRTNA ERDS to the County and for returning payloads from the County to the CeRTNA ERDS. The folder structure can be based on physical or mapped drive letters or on UNC paths. The default configuration is based on a physical drive as follows:
View Source
Folder structure. The folder structure of a DIP containing relational databases in SIARD format is fully compliant with the folder structure of E-ARK Information Packages described in section 4.1 of the Introduction to the Common Specification for Information Packages in the E-ARK Project. In the case where the IP contains more than one representation of the database, the difference between the representations must be indicated in PREMIS. Different representations should be treated as different (representation) object entities belonging to the same intellectual (object) entity. The relationship between the representations can be expressed by the semantic unit (PREMIS) “relationship”. This semantic unit includes “relationshipType” and “relationshipSubType” as semantic components. In regard to the recommendation to use PREMIS, both components’ values should be taken from a controlled vocabulary. The documentation folder should include all relevant OLAP specific data which may be: 1. A textual description of the definition of the OLAP objects. 2. Vendor specific exports (files) of the OLAP cube. 3. Vendor specific documentations to particular software tools for creating and analysing OLAP data. 4. Software tools for creating and analysing OLAP data (always together with sufficient documentation). Primary data of the rdb to be delivered to the user are stored in the form of a SIARD db. The actual content of a SIARD db within an E-ARK DIP will be a subset of the content of the SIARD db (from a certain representation) of the AIP.
View Source
Folder structure. The folder tree representing a 6G Library Object is presented in Figure 2. Three main folders are used, namely the private, the public and the documentation folder. This folder contains the component public information that could be used by third parties to integrate the catalogue. • description.yaml (file): Is a descriptor file with the component public information. It contains metadata (component name, version, etc., ...) and the public variables that should be used to deploy it. • changelog.yaml (file): Is a file with the component historical evolution: new version, bug fixing, etc. This folder contains the component private files with information and automation that will be used to deploy the component in a 6G-SANDBOX site. • values.yaml (file): Contains variables needed by automation tools to accomplish deployment and configuration • manifest.yaml (file): Contains the flow that must be followed to deploy the component • cloud_provider(folder): One folder per cloud provider where the component will be available o cac (folder): Contains files related to configuration automation ▪ pre(folder): Contains files related to configuration that should be done in advance. For example, gather some information from cloud provider. ▪ install(folder): Contains files related to component configuration ▪ post(folder): Contains files related to configuration that should be done after component set-up. For example, test execution. o Iac (folder): Contains files related to infrastructure definition It contains detailed information about the component in Markdown editor format, to enable direct integration between third parties and the catalogue.
View Source
Folder structure. Within the IP geodata will be structured according to the representation-based model as shown in Figure 2 – Folder structure of the geodata DIP below: 109 Described in greater detail in the chapter 4.3 of the official deliverable D.4.3.
View Source
Folder structure. The folder structure of a DIP containing a relational database in SIARD format is fully compliant with the folder structure of the E-ARK Information Packages described in section 4.1 of the Introduction to the Common Specification for Information Packages in the E-ARK Project.
View Source
Folder structure. The folder structure should reflect the archival structure of the records and the piece and item levels should also be reflected in the file naming. If the records were from the series CAB 129 they should be grouped in folders as below (folder titles are in bold): • Top level folder should reflect the dept code_series number e.g. CAB_129 • The next folder should be named content (with a small 'c'): content • The next folder should reflect the piece number e.g. 179 • The next folder should reflect the item* number e.g. 7 The files for each item should be contained in the item folder to which they relate. Where there is no item the images will be contained in the piece folder to which they relate. As an example, the folder structure for the files from CAB 129/179/7 would look like this: CAB_129 (Deptcode_seriesnumber) content (folder named ‘content’) 179 (piece level folder) 7 (item level folder ) 179_7_0001.tif (file 1) 179_7_0002.tif (file 2) * The item level is optional as it depends on the collection but sub series, sub sub series and sub items should not be represented in the folder structure.
View Source

Related to Folder structure

  • Master Feeder Structure If permitted by the 1940 Act, the Board of Trustees, by vote of a majority of the Trustees, and without a Shareholder vote, may cause the Trust or any one or more Series to convert to a master feeder structure (a structure in which a feeder fund invests all of its assets in a master fund, rather than making investments in securities directly) and thereby cause existing Series of the Trust to either become feeders in a master fund, or to become master funds in which other funds are feeders.

  • Agreement Structure This Agreement includes Part 1 - General Terms, Part 2 - Country-unique Terms (if any), the LI, and the ▇▇▇ and is the complete agreement between Licensee and Lenovo regarding the use of the Program. It replaces any prior oral or written communications between Licensee and Lenovo concerning Licensee’s use of the Program. The terms of Part 2 may replace or modify those of Part 1. To the extent of any conflict, the LI prevails over both Parts.

  • Management Structure Describe the overall management approach toward planning and implementing the contract. Include an organization chart for the management of the contract, if awarded.

  • Framework Management Structure The Supplier shall provide a suitably qualified nominated contact (the “Supplier Framework Manager”) who will take overall responsibility for delivering the Goods and/or Services required within this Framework Agreement, as well as a suitably qualified deputy to act in their absence. The Supplier shall put in place a structure to manage the Framework in accordance with Framework Schedule 2 (Goods and/or Services and Key Performance Indicators). A full governance structure for the Framework will be agreed between the Parties during the Framework Agreement implementation stage. Following discussions between the Parties following the Framework Commencement Date, the Authority shall produce and issue to the Supplier a draft Supplier Action Plan. The Supplier shall not unreasonably withhold its agreement to the draft Supplier Action Plan. The Supplier Action Plan shall, unless the Authority otherwise Approves, be agreed between the Parties and come into effect within two weeks from receipt by the Supplier of the draft Supplier Action Plan. The Supplier Action Plan shall be maintained and updated on an ongoing basis by the Authority. Any changes to the Supplier Action Plan shall be notified by the Authority to the Supplier. The Supplier shall not unreasonably withhold its agreement to any changes to the Supplier Action Plan. Any such changes shall, unless the Authority otherwise Approves, be agreed between the Parties and come into effect within two weeks from receipt by the Supplier of the Authority’s notification. Regular performance review meetings will take place at the Authority’s premises throughout the Framework Period and thereafter until the Framework Expiry Date (“Supplier Review Meetings”). The exact timings and frequencies of such Supplier Review Meetings will be determined by the Authority following the conclusion of the Framework Agreement. It is anticipated that the frequency of the Supplier Review Meetings will be once every month or less. The Parties shall be flexible about the timings of these meetings. The purpose of the Supplier Review Meetings will be to review the Supplier’s performance under this Framework Agreement and, where applicable, the Supplier’s adherence to the Supplier Action Plan. The agenda for each Supplier Review Meeting shall be set by the Authority and communicated to the Supplier in advance of that meeting. The Supplier Review Meetings shall be attended, as a minimum, by the Authority Representative(s) and the Supplier Framework Manager.

  • Payment Structure You must pay the fees listed on the relevant Services Order. Subscription payments will be structured differently based on the term you select from the three options below and the payment structure will be set forth in the Services Order. The fees identified in the Services Order are exclusive of shipping fees, and you will pay the shipping fees (if applicable) identified in the invoice.