EAD Sample Clauses

EAD. Descriptive metadata are used to describe the intellectual contents of archival holdings, and they support finding and understanding individual information packages. The E-ARK project allows for the inclusion of any kind of descriptive metadata in the E-ARK IP54. These go into the ‘descriptive/’ folder as seen in the example below, Figure 3 (cf. EAD.xml). Figure 3 - E-ARK IP descriptive metadata The METS descriptive metadata element <dmdSec> references descriptive metadata as seen in Figure 4 below and as such descriptive metadata are not to be included into the METS file. Figure 4 - METS descriptive metadata The EAD file has three main inputs (Figure 5 below): ● Archival descriptions. Contains main archival descriptions (including metadata about aggregations and classification). 54 For E-ARK pilots, most of the Access Software used the EAD3 standard. They can however be tweaked to use other descriptive metadata. ● Content. Contains links to computer files and folders as <dao> elements and @base attributes respectively. ● Additional metadata. Specific information that does not fit into the EAD3 standard elements can be saved as <odd> elements or localtype attributes in EAD3 elements (see localtype example below in section ‘Search’).
Sample 1
AutoNDA by SimpleDocs
EAD. EAD metadata is the main tool for understanding and using the content of the SMURF ERMS DIP. In general EAD metadata must follow the rules set out in the core DIP specification (see Chapter 3 The DIP) and the core SMURF specification (D3.4 E-ARK SIP Specification: xxxx://xxx.xxxx-xxxxxxx.xxx/resources/project- deliverables/93-d34-1). For the development of appropriate access tools (viewers) we expect that the following EAD elements are available and filled with appropriate information: ● The title for each descriptive unit within the package (element did/unittitle) ● The creation date of the record or descriptive unit (one of the elements did/unitdate or did/unitdatestructured) ● Each descriptive unit which has a physical counterpart as a folder or computer file(s) within the package’s folder structure must use the element did/dao along with the @href attribute referring to the relative location of the folder or file. In case the reference is to a record which includes multiple computer files, the use of the element did/daoset is required ● Identification of aggregation level(s) and records (using the @level attribute on the archdesc or c element) ● archival history of the record (using the custodhist element) ● if applicable, EAD metadata must also include information about any access restrictions to the records (using the accessrestrict element) ● the original classification schema in full or in part (using the fileplan element); ● full ERMS originated metadata about the aggregation level(s) and records (embedded into EAD using the odd element at the appropriate c-level); ● relevant metadata about the actors and events as exported from the source ERMS and recorded in the extended EAD (sub-elements of the EAD element odd as described in D3.3 SMURF specification, for example information about signatures, opening and closing of the file, etc.) Full example: <?xml version="1.0" encoding="utf-8"?> <ead xmlns="xxxx://xxx0.xxxxxxxxxx.xxx/schema/" xmlns:xsi="xxxx://xxx.x0.xxx/2001/XMLSchema- instance" xsi:schemaLocation="xxxx://xxx0.xxxxxxxxxx.xxx/schema/ ../../schemas/ead3.xsd"> <control> <recordid>f323992d-bfa0-4586-bc1b-090d06ec6a72</recordid> <filedesc> <titlestmt> <titleproper>University of Utopia</titleproper> </titlestmt> </filedesc> <maintenanceagency> <agencyname>University of Utopia</agencyname> </maintenanceagency> <maintenancehistory> <maintenanceevent> <eventtype value="created"></eventtype> <eventdatetime>2016-07-08T08:50:52.1200000</eventdatetime>...
Sample 1
EAD. In order to describe a database in EAD it is suggested that the value of the attribute level should be set to “otherlevel” and that the value in the following otherlevel attribute should be set to “database”, see the following example where a database description is at the highest hierarchical level: <archdesc level="otherlevel" otherlevel="database" lang="eng"> <did> <unittitle>Northwind database</unittitle> <dao daotype="borndigital" href="/representations/AVID.SA.18006_rep0/data/northwind.siard"></dao> <unitdate>2000-2008</unitdate> <abstract lang="eng">Northwind Traders Access database is a sample database from Microsoft Office suite. The Northwind database contains the sales data for a fictitious company called Northwind Traders, which imports and exports specialty foods from around the world. The database contains 13 tables and also includes pictures of foods and employees. </abstract> <!-- EAD file continues but further elements left out in this example-->
Sample 1
EAD. 3.3.3.3.1 EAD files xxxxx://xxxxxx.xxx/DLMArchivalStandardsBoard/E-ARK-DIP/tree/master/examples/OLAP
Sample 1
EAD. The necessary prerequisite for the application of the SMURF SFSB profile is that a simple archival description has been created using EAD. In the most common scenario this EAD description would include a few aggregations (possibly following the original folder structure) and simple descriptions of the content itself. There are a few EAD elements which are deemed mandatory in order to allow for the development of common access tools: ● The title for each aggregation (element did/unittitle) ● The creation date of the record or aggregation (one of the elements did/unitdate or did/unitdatestructured) ● Each descriptive unit which has a physical counterpart as a folder or computer file(s) within the package’s folder structure must use the element did/dao along with the @href attribute referring to the relative location of the folder or file. In case the reference is to a record which includes multiple computer files, the use of the element did/daoset is required Besides these elements the rules for EAD as highlighted above for the core DIP and within the core SMURF SFSB specification need to be followed. Full example: <?xml version="1.0" encoding="utf-8"?> <ead xmlns="xxxx://xxx0.xxxxxxxxxx.xxx/schema/" xmlns:xsi="xxxx://xxx.x0.xxx/2001/XMLSchema- instance" xsi:schemaLocation="xxxx://xxx0.xxxxxxxxxx.xxx/schema/ ../../schemas/ead3.xsd"> <control> <recordid>f323992d-bfa0-4586-bc1b-090d06ec6a72</recordid> <filedesc> <titlestmt> <titleproper>Personal letters of Mr Private Person</titleproper> </titlestmt> </filedesc> <maintenanceagency> <agencyname>National Archives of Utopia</agencyname> </maintenanceagency> <maintenancehistory> <maintenanceevent> <eventtype value="created"></eventtype> <eventdatetime>2016-07-08T08:50:52.1200000</eventdatetime> <agenttype value="human">text</agenttype> <agent>Utopian Recordsmanager</agent> </maintenanceevent> </maintenancehistory> </control> <archdesc level="series"> <did> <unitid label="current">FNS.11-2</unitid> <abstract>Personal letters of Mr Private Person</abstract> <origination label="Creator"> <name> <part>Mr Private Person</part> </name> </origination> </did> <dsc> <c level="item"> <did> <unitid localtype="current">FNS.112-2-1</unitid> <unittitle>Report 01</unittitle> <unitdate datechar="created">20.01.2008</unitdate> <abstract>Report No. 3</abstract> <physdescstructured coverage="whole" physdescstructuredtype="spaceoccupied"> <quantity>0.0138</quantity> <unittype>MB</unittype> </physdescstructured> <dao id="c90fc089-1986...
Sample 1
EAD. Since geodata IP’s are in general a subtype of a SMURF SFSB, all the requirements for EAD metadata are equal to the specifications mentioned in the chapter 3.5.2.3. Always when the content of a geodata IP is changed in a way that affects positional accuracy (i.e. generalisation or transformation) the EAD metadata description must reflect the new accuracy values. The element “Lineage” must be updated and the element “Spatial resolution” must be updated to the new value. In the case below an administrative unit’s spatial dataset was generalised. The accuracy changes from 1:2880 to 1:50000. <odd> <head>Lineage</head> <p>This dataset was created by manually digitizing the original cadastral maps in various scales (1:1000, 1:1440 and 1:2880). The whole dataset was created by merging individual units, that were digitised by different authors, since different municipalities had different service providers. The base datasets were created in the period from 1984 to 1994 and were subsequently added to create the final dataset. Boundaries were generalised for a faster display.</p> </odd> <odd> <head>SpatialResolution</head> <p>50000</p> </odd> Table 33 - EAD example of changing content of geodata IP (in this case elements Lineage and Spatial resolution)
Sample 1

Related to EAD

  • Entrance Salary New employees shall generally be appointed at the minimum step of the salary range established for the particular class of position to which the appointment is made. However, the appointing authority may fill a particular position at a step above the minimum of the range.

  • Salary No salary will be paid to a Member for the performance of his or her duties under this Agreement unless the salary has been approved in writing by a Majority of the Members.

  • Time of Vacation (a) All vacation earned during one (1) vacation year shall be taken during the next following vacation year at a mutually agreeable time.

  • Salary Administration Section 1. Salary eligibility date is defined as the date an employee is eligible for an annual performance pay increase. The salary eligibility date is computed from the date of hire. Employees shall be eligible for annual performance pay increases on the employees' salary eligibility date provided the employee is not at the top step of the salary range of the employees' classification. The employee may be denied the annual performance pay increase if there has been a serious performance or attendance problem. Denials are subject to review within six (6) months. Denials may be grieved under the provisions of Article 51.

  • Number of Employees The Union and the Employer agree that no more than one (1) position in each program shall be covered by a Job Sharing Agreement at any one time. No more than two (2) employees may share one (1) full-time position. The position being shared shall remain a regular full-time position within the bargaining unit.

  • Salary Scales 1. In the settlement of the Kindergarten Teachers, Head Teachers and Senior Teachers' Collective Agreement 2000-2002 the parties committed themselves to the implementation of pay parity for kindergarten teachers. Senior teacher K3 and K4 salaries were benchmarked to the base salary (excluding the roll-based supplementary component) of a primary U2 and U3 principal respectively.

  • Longevity Bonus Effective 2005, twenty (20) years of continuous service, an employee will receive a longevity bonus of seven hundred dollars ($700.00) per year, payable in one lump sum by the second pay period following the employee's anniversary date.

  • Salary Scale The salary scale applicable to Employees shall be set out hereinafter in the Wage Schedule.

  • Employee Compensation The wages, salaries and other compensation paid to employees who will be employed for the benefit of the Project, and to others who perform special services for the benefit of the Project, to the extent not otherwise paid through a Cash Management System, shall be paid by Owner from a Project Account pursuant to this Section 9.2.

  • Plan Brochure The Hospital will pay 75% of the billed premium towards coverage of eligible employees under the long-term disability portion of the Plan (HOODIP or an equivalent plan as described in the August, 1992 booklet (Part B)), the employee paying the balance of the billed premium through payroll deduction. For the purpose of transfer to the short- term portion of the disability program, employees on the payroll as of the effective date of the transfer with three (3) months or more of service shall be deemed to have three (3) months of service. For the purpose of transfer to the long- term portion of the disability program, employees on the active payroll as of the effective date of the transfer with one (1) year or more of service shall be deemed to have one (1) year of service.

Time is Money Join Law Insider Premium to draft better contracts faster.