DOCSLIB.ORG

2. Common HOPE Metadata Structure

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
2. Common HOPE Metadata Structure HOPE Heritage of the People’s Europe Grant agreement No. 250549 Deliverable D2.2 The Common HOPE Metadata Structure, including the Harmonisation Specifications Deliverable number D2.2 Version 1.1 Authors Bert Lemmens – Amsab-ISG Joris Janssens – Amsab-ISG Ruth Van Dyck – Amsab-ISG Alessia Bardi – CNR-ISTI Paolo Manghi – CNR-ISTI Eric Beving – UPIP Kathryn Máthé – KEE-OSA Katalin Dobó – KEE-OSA Armin Straube – FES-A Delivery Date 31/05/2011 Dissemination Level Public HOPE is co-funded by the European Union through the ICT Policy Support Programme D2.2 Common HOPE Metadata Structure & Harmonisation Requirements V1.1 – 31/05/2011 Page 2 of 266 HOPE is co-funded by the European Union through the ICT Policy Support Programme D2.2 Common HOPE Metadata Structure & Harmonisation Requirements V1.1 – 31/05/2011 Page 3 of 266 Table of Contents Table of Contents 3 1. Introduction 8 1.1 Task Description 8 1.2 Approach 10 1.2.1 Task breakdown 10 1.2.2. Dublin Core Application Profile Guidelines 14 1.2.3. Used Terminology 15 1.2.4. Structure of the Document 17 1.3 Glossary 18 1.3.1 Hope glossary 18 1.3.2 Technical Glossary 18 2. Common HOPE Metadata Structure 24 2.1 Functional requirements 24 2.1.1 General 24 2.1.1.1 What does HOPE want to accomplish with the HOPE Aggregator? 24 2.1.1.2 What the HOPE Aggregator will not attempt to do? 26 2.1.2. Aggregation 26 2.1.2.1 What are the key characteristics of the HOPE metadata? 27 2.1.2.2 How do the characteristics of the HOPE metadata affect the design of the Common HOPE Metadata Structure? 28 2.1.3. Dissemination 30 2.1.3.1 What are the key characteristics of the HOPE users? 30 2.1.3.2 How does the HOPE System want to serve its users? 31 2.1.3.3 Listing the Functional Requirements of the Common HOPE Metadata Structure 33 2.2 Transformation Procedure 36 2.2.1. Definitions 36 2.2.2 Transformation Procedure 37 2.2.3. Transformation Issues regarding Semantic Interoperability 40 2.3 HOPE Data Model 42 2.3.1 Introduction 42 HOPE is co-funded by the European Union through the ICT Policy Support Programme D2.2 Common HOPE Metadata Structure & Harmonisation Requirements V1.1 – 31/05/2011 Page 4 of 266 2.3.2 HOPE Data Model 55 2.3.2.1 Diagram 55 2.3.2.2 Entities 56 2.4 HOPE Domain Profiles 119 2.4.1 Introduction 119 2.4.1.1 Purpose of domain profiles 119 2.4.1.2 Definition of domain profiles 120 2.4.2 HOPE Domain Profiles 122 2.4.2.1 HOPE archive profile 124 2.4.2.2 HOPE library profile 127 2.4.2.3 HOPE visual profile 131 2.4.2.4 HOPE audio-visual profile 135 2.4.2.5 HOPE Dublin Core profile 138 2.5 HOPE XML Schema 141 2.5.1 Introduction 141 2.5.2 XML Schema 142 2.5.2.1 Enumerations 142 2.5.2.2 Domain 143 2.5.2.3 Bi-/one-directional relationships 143 2.5.3 Structure of the XML Schema 144 2.5.3.1 Entity level 144 2.5.3.2 Complex types 145 3. Harmonisation Requirements 153 3.1 Local and Persistent Identifiers 153 3.1.1 Introduction 153 3.1.1.1 Objective 153 3.1.1.2 Survey Results 154 3.1.2. General requirements 154 3.1.2.1 General requirement 01: identifiers and URLs 154 3.1.2.2. General requirement 02 : persistence of identifiers and URLs 155 3.1.2.3. General requirement 03: uniqueness of identifiers 155 3.1.2.4. General requirement 04: identifiers (except PIDs) should not be URLs 156 3.1.3. PID services and resolver services 156 HOPE is co-funded by the European Union through the ICT Policy Support Programme D2.2 Common HOPE Metadata Structure & Harmonisation Requirements V1.1 – 31/05/2011 Page 5 of 266 3.1.3.1. What is a PID service? 156 3.1.3.2 Requirements for the usage of PIDs in the HOPE System - Glossary 159 3.1.3.3 Requirements for the HOPE PID Service 161 3.1.4. Scenarios and requirements for creation, supply and update of identifiers by content providers 161 3.1.4.1 Structure of scenarios 162 3.1.4.2 Requirements for metadata records (i.e. descriptive units) and landing pages 162 3.1.4.3 Requirements for digital files 164 3.1.4.4 Requirements for CP authority records 172 3.2. Granularity 175 3.2.1 Survey Results 175 3.2.2 Europeana and Granularity 176 3.2.3 Recording Granularity in the Common HOPE Metadata Structure 177 3.2.4 Hierarchical Descriptions in the Descriptive Unit Entity 178 3.2.4.1 Elements 178 3.2.4.2 Hierarchical structures 182 3.2.5 Compound Digital Objects in the Digital Resource Entity 194 3.2.5.1 Elements 198 3.2.5.2 Acceptance Levels 200 3.3. Descriptive and Administrative Metadata 203 3.3.1 Mandatory, Recommended & Optional Elements 203 3.3.1.1 HOPE Aggregator 204 3.3.1.2 Europeana 205 3.3.1.3 HOPE@Europeana: 207 3.3.1.4 IALHI Portal 207 3.3.2. Metadata Normalisation 213 3.3.2.1 Dates 214 3.3.2.2 Languages 216 3.3.2.3 Scripts 218 3.3.2.4 Description Level 219 3.3.2.5 Rights 220 3.3.2.6 Type 221 4. Case Studies Semantic Enrichment 223 HOPE is co-funded by the European Union through the ICT Policy Support Programme D2.2 Common HOPE Metadata Structure & Harmonisation Requirements V1.1 – 31/05/2011 Page 6 of 266 4.1. Common HOPE Authorities 223 4.1.1.Survey results 223 4.1.1.1 Content Providers Survey 223 4.1.1.2 Additional Survey 225 4.1.2. Mapping and merging procedure 227 4.1.2.1 HOPE Authority File Manager Tool 227 4.1.2.2 Agents 230 4.1.2.3 Places 231 4.1.2.4 Concepts 232 4.1.2.5 Events 232 4.1.3 HOPE Themes 233 4.2. Multilingual Access 235 4.2.1 Introduction 235 4.2.1.1 Sources of information 235 4.2.1.2 Purpose of this document 235 4.2.1.3 Building a multilingual controlled vocabulary 237 4.2.2 Hope Metadata: Language and Scripts, Translations and Transliterations 238 4.2.2.1 Languages / translations 238 4.2.2.2 Scripts / transliterations 239 4.2.3 Resources, Tools and Services 241 4.2.3.1 Introduction 241 4.2.3.2 Availability of controlled vocabularies and tools 242 4.2.3.3 MultiMatch project 243 4.2.3.4 EuropeanaConnect 244 4.2.3.5 Hitime 246 4.2.3.6 Multilingual vocabularies for subjects / topical terms 247 4.2.3.7 Conclusion 249 4.2.4 Recording Multilingual HOPE Metadata 252 4.2.4.1 Translation issues 252 4.2.4.2 Transliteration issues 255 4.2.4.3 Issues related to the use of special characteristics and diacritics 259 4.2.5 Enrichment: Building Multilingual HOPE Metadata 262 Labels 262 HOPE is co-funded by the European Union through the ICT Policy Support Programme D2.2 Common HOPE Metadata Structure & Harmonisation Requirements V1.1 – 31/05/2011 Page 7 of 266 Linked Data 262 Online Translation Tools 262 Transliterations 262 Multilingual vocabularies 263 Persons & Places 263 HOPE Historical Themes 264 BIBLIOGRAPHY 266 APPENDIX A, B, C 266 HOPE is co-funded by the European Union through the ICT Policy Support Programme D2.2 Common HOPE Metadata Structure & Harmonisation Requirements V1.1 – 31/05/2011 Page 8 of 266 1. Introduction This chapter includes the description of the tasks 2.3 and 2.4 as presented in the HOPE Description of Work and the way these tasks have been approached. 1.1 Task Description This deliverable includes the specifications for the Common HOPE Metadata Structure and the subsequent harmonization requirements. These specifications and requirements have been drafting within the scope Tasks 2.3 and 2.4 of the HOPE Description of Work. The task description of these two tasks reads as follows: T2.3 Specification of the common metadata structure This task deals with the HOPE data model at the more syntactical level. T2.3.1 An inventory will be made of the metadata standards and schemes applied locally by the participants, the level of granularity of the descriptive units and the local practices for producing previews/thumbnails (low res scans, video stills, etc.) and the use of unique identifiers for referential integrity. These will be matched with the Europeana specifications (metadata scheme, previews/thumbnails sizes and formats and the object link) in order to assess the range of interoperability issues and the extent of the harmonization and enrichment work that needs to be done. T2.3.2 This task will then specify a common metadata structure for interoperability within HOPE and full-interoperability with Europeana. This will include: Specification of the overall metadata framework Agreed standards for metadata (descriptive, admin and structural) Agreed levels of descriptive granularity per content object type (collection, archive, book, periodical, image, etc.) Agreed standards for digital content representations (thumbnails, preview, low-res, etc.) per content object type Agreed common format for cross-searching Requirements for resolvable identifiers (incl. requirements for ensuring that the identifiers are compatible with different resolution solutions in case of migration from one solution to another) The specifications of the common HOPE metadata structure (incl.
Load more

Recommended publications
  • Technical Reference Manual for the Standardization of Geographical Names United Nations Group of Experts on Geographical Names
    ST/ESA/STAT/SER.M/87 Department of Economic and Social Affairs Statistics Division Technical reference manual for the standardization of geographical names United Nations Group of Experts on Geographical Names United Nations New York, 2007 The Department of Economic and Social Affairs of the United Nations Secretariat is a vital interface between global policies in the economic, social and environmental spheres and national action. The Department works in three main interlinked areas: (i) it compiles, generates and analyses a wide range of economic, social and environmental data and information on which Member States of the United Nations draw to review common problems and to take stock of policy options; (ii) it facilitates the negotiations of Member States in many intergovernmental bodies on joint courses of action to address ongoing or emerging global challenges; and (iii) it advises interested Governments on the ways and means of translating policy frameworks developed in United Nations conferences and summits into programmes at the country level and, through technical assistance, helps build national capacities. NOTE The designations employed and the presentation of material in the present publication do not imply the expression of any opinion whatsoever on the part of the Secretariat of the United Nations concerning the legal status of any country, territory, city or area or of its authorities, or concerning the delimitation of its frontiers or boundaries. The term “country” as used in the text of this publication also refers, as appropriate, to territories or areas. Symbols of United Nations documents are composed of capital letters combined with figures. ST/ESA/STAT/SER.M/87 UNITED NATIONS PUBLICATION Sales No.
    [Show full text]
  • RDAP Transformation of Contact Information Draft-Lozano-Regext-Rdap-Transf-Contact-Inf-00
    Internet Engineering Task Force G. Lozano Internet-Draft ICANN Intended status: Standards Track Jun 24, 2016 Expires: December 26, 2016 RDAP Transformation of Contact Information draft-lozano-regext-rdap-transf-contact-inf-00 Abstract This document adds support for RDAP Transformation (i.e. translation and transliteration) of Contact Information. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 26, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
    [Show full text]
  • Sc22/Wg20 N860
    Final Draft for CEN CWA: European Culturally Specific ICT Requirements 1 2000-10-31 SC22/WG20 N860 Draft CWA/ESR:2000 Cover page to be supplied. Final Draft for CEN CWA: European Culturally Specific ICT Requirements 2 2000-10-31 Table of Contents DRAFT CWA/ESR:2000 1 TABLE OF CONTENTS 2 FOREWORD 3 INTRODUCTION 4 1 SCOPE 5 2 REFERENCES 6 3 DEFINITIONS AND ABBREVIATIONS 6 4 GENERAL 7 5 ELEMENTS FOR THE CHECKLIST 8 5.1 Sub-areas 8 5.2 Characters 8 5.3 Use of special characters 10 5.4 Numbers, monetary amounts, letter written figures 11 5.5 Date and time 12 5.6 Telephone numbers and addresses, bank account numbers and personal identification 13 5.7 Units of measures 14 5.8 Mathematical symbols 14 5.9 Icons and symbols, meaning of colours 15 5.10 Man-machine interface and Culture related political and legal requirements 15 ANNEX A (NORMATIVE) 16 Final Draft for CEN CWA: European Culturally Specific ICT Requirements 3 2000-10-31 FOREWORD The production of this document which describes European culturally specific requirements on information and communications technologies was agreed by the CEN/ISSS Workshop European Culturally Specific ICT Requirements (WS-ESR) in the Workshop’s Kick-Off meeting on 1998-11-23. The document has been developed through the collaboration of a number of contributing partners in WS-ESR. WS- ESR representation gathers a wide mix of interests, coming from academia, public administrations, IT-suppliers, and other interested experts. The present CWA (CEN Workshop Agreement) has received the support of representatives of each of these sectors.
    [Show full text]
  • Standards and Standardisation a Practical Guide for Researchers
    Standards and Standardisation A practical guide for researchers Research and Innovation Europe Direct is a service to help you find answers to your questions about the European Union. Freephone number (*): 00 800 6 7 8 9 10 11 (*) Certain mobile telephone operators do not allow access to 00 800 numbers or these calls may be billed. More information on the European Union is available on the Internet (http://europa.eu). Cataloguing data can be found at the end of this publication. Luxembourg: Publications Office of the European Union, 2013 ISBN 978-92-79-25971-5 doi: 10.2777/10323 © European Union, 2013 Reproduction is authorised provided the source is acknowledged. Cover image: © Andrea Danti, #12386685, 2012. Source: Fotolia.com Printed in Luxembourg EUROPEAN COMMISSION DIRECTORATE-GENERAL FOR RESEARCH & INNOVATION Directorate G - Industrial technologies Standards A practical and Standardisation guide for researchers Author Dr. Peter Hatto LEGAL NOTICE Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of the following information. The views expressed in this publication are the sole responsibility of the author and do not necessarily reflect the views of the European Commission. More information on the European Union is available on the Internet (http://europa.eu). EUROPEAN COMMISSION Directorate-General for Research & Innovation Directorate G – Industrial Technologies Unit G1 – Horizontal Aspects E-mail: [email protected] Contact: Romain Bouttier
    [Show full text]
  • Centc304 N932
    CEN/TC304 N932 Source: Secretariat Date: 15 Dec 1999 Title: European Fallback Rules, ballot Mailed: 15 Dec 1999 Status: TC-enquiry: DEADLINE 1st March 2000 Action required: Respond before 1 March 2000 * Notes: This is a TC-enquiry, to establish the suitability of N932 to be sent for Formal vote as prENV. National member body officers, responsible for CEN/TC304 issues are asked to fill in this form and send it to the TC-secretariat before 1 March 2000. Comments in any form will be forwarded to the CEN/TC 304 Project Team of European Fallback Rules. The PT will before the next plenary of TC304 in April 2000 produce a disposition of comments and a revised draft. The PT will produce a disposition of comments and plans to ask the TC304 plenary in November to approve a revised draft to be sent for Formal Vote. Comments from affiliated members of CEN and liaisons are welcome and will be considered. Country:______________________________ Approves without comments ___ Approves with comments ___ Disapproves with comments ___ Date:_______________ Signature_____________________________________(National Member Body officer) Name:__________________________________ EUROPEAN PRESTANDARD DRAFT PRÉNORME EUROPÉENNE prENV_____ EUROPÄISCHE VORNORM ICS: 35.040 Descriptors: Data processing, information interchange, text processing, text communication, graphic characters, character sets, representation of characters, coded character sets, conversion, fallback English version Information Technology European fallback rules Technologies de l'information- Informations technologies Character repertoire and coding transformations: Character repertoire and coding transformations: European fallback rules - Nº 1 European fallback rules - Nº 1 This draft ENV is submitted to CEN members for Formal Vote. It has been drawn up by the Technical Committee CEN/TC 304.
    [Show full text]
  • Definition of Object-Oriented FRBR
    FRBR object-oriented definition and mapping from FRBRER, FRAD and FRSAD Document Type: Current Editorial Status: In Progress since [5/4/2017] Version 3.0 September 2017 International Working Group on FRBR and CIDOC CRM Harmonisation Supported by Delos NoE Editors: Chryssoula Bekiari Martin Doerr Patrick Le Bœuf Pat Riva Contributors: Trond Aalberg, Jérôme Barthélémy, Chryssoula Bekiari, Guillaume Boutard, Martin Doerr, Günther Görz, Dolores Iorizzo, Max Jacob, Carlos Lamsfus, Patrick Le Bœuf, Mika Nyman, João Oliveira, Christian Emil Ore, Allen H. Renear, Pat Riva, Richard Smiraglia, Stephen Stead, Maja Žumer, and others November 2015 Index INDEX ............................................................................................................................................... 2 FOREWORD ................................................................................................................................. 109 1. INTRODUCTION ..................................................................................................................... 1110 1.1. Purposes .................................................................................................................................................... 1110 1.1.1. A Common View of Cultural Heritage Information .......................................................................... 1211 1.1.2. A Verification of FRBR’s Internal Consistency ................................................................................ 1211 1.1.3. An Enablement of Information
    [Show full text]
  • Inventory of Romanization Tools
    Inventory of Romanization Tools Standards Intellectual Management Office Library and Archives Canad Ottawa 2006 Inventory of Romanization Tools page 1 Language Script Romanization system for an English Romanization system for a French Alternate Romanization system catalogue catalogue Amharic Ethiopic ALA-LC 1997 BGN/PCGN 1967 UNGEGN 1967 (I/17). http://www.eki.ee/wgrs/rom1_am.pdf Arabic Arabic ALA-LC 1997 ISO 233:1984.Transliteration of Arabic BGN/PCGN 1956 characters into Latin characters NLC COPIES: BS 4280:1968. Transliteration of Arabic characters NL Stacks - TA368 I58 fol. no. 00233 1984 E DMG 1936 NL Stacks - TA368 I58 fol. no. DIN-31635, 1982 00233 1984 E - Copy 2 I.G.N. System 1973 (also called Variant B of the Amended Beirut System) ISO 233-2:1993. Transliteration of Arabic characters into Latin characters -- Part 2: Lebanon national system 1963 Arabic language -- Simplified transliteration Morocco national system 1932 Royal Jordanian Geographic Centre (RJGC) System Survey of Egypt System (SES) UNGEGN 1972 (II/8). http://www.eki.ee/wgrs/rom1_ar.pdf Update, April 2004: http://www.eki.ee/wgrs/ung22str.pdf Armenian Armenian ALA-LC 1997 ISO 9985:1996. Transliteration of BGN/PCGN 1981 Armenian characters into Latin characters Hübschmann-Meillet. Assamese Bengali ALA-LC 1997 ISO 15919:2001. Transliteration of Hunterian System Devanagari and related Indic scripts into Latin characters UNGEGN 1977 (III/12). http://www.eki.ee/wgrs/rom1_as.pdf 14/08/2006 Inventory of Romanization Tools page 2 Language Script Romanization system for an English Romanization system for a French Alternate Romanization system catalogue catalogue Azerbaijani Arabic, Cyrillic ALA-LC 1997 ISO 233:1984.Transliteration of Arabic characters into Latin characters.
    [Show full text]
  • State of the Standards, January 31, 2012
    O O S C E ing f R D O SERU (SHAREd E-Res OURCE UndERS arTTanding)Icle St St O EXCERPted FRom: ISO/TR 14873 ISO/TR ES CORE (C CORE RI A 25964-1 R O B I IS ISO/ TR 11219 ISO/ n L I RFID Z39.7 DATa DicTIONARy STAN DicTIONARy DATa Z39.7 ISO 5127 ISO 8 INFORMATION STANDARDS QuARTERLY WINTER 2012 | VOL 24 | ISSUE 1 | ISSN 1041-0031 SPECIAL EDITION: YEAR IN REVIEW AND STATE OF THE STANDARDS ISO/TR 17068 ISO 13008 ISO 17316 ISO 3166 ISO 17316 11219 2789 O TR / IS O KBART PHASe 2 IS Open DisCOVERy INITIATIVE TE TE I ISO 13008 ISO Su NISO and TC46 G A ISO 2709 ISO T 2011 Year In REVIEW t GrOUP E S G cle I RT From ISO 2788 to ISO 25964: A al Intere The EVOLUTIon oF I on exCHAN I THESAURUS STANDARDS 17316 27729 O O IS IS S: Journal AT J DEVELopment oF RESOURCE NFORMAT -book SpeC I E SYNCHRONIZATIon STANDARD ISO 9:1995 STATE OF THE ORMAt ORMAt For F STANDARDS 16175-2 2709:2008, 2709:2008, O O IS IS SS 31 [SPECIAL EDITION] STATE OF THE 31,2012 ANUARY STANDARDS J This comprehensive report on NISO’s standards and initiatives appears in the first issue of the year of ISQ to keep readers informed of the scope and status of NISO’s program on an annual basis. If you have questions about any of the standards or development programs, contact the NISO office by phone (301-654-2512), via e-mail ([email protected]), or visit the Standards section of the NISO website (www.niso.org/standards).
    [Show full text]
  • Bsdploy Documentation Release 2.4.0.Dev0
    bsdploy Documentation Release 2.4.0.dev0 Tom Lazar Dec 22, 2017 Contents 1 Main Features 3 2 How it works 5 3 Example Session 7 4 Best of both worlds 9 5 Under the hood 11 6 Full documentation 13 7 Dive in 15 7.1 Client requirements........................................... 15 7.2 Server requirements........................................... 15 7.3 Client Installation............................................ 16 7.4 Quickstart................................................ 17 8 Tutorial 23 8.1 Tutorial.................................................. 23 8.2 Webserver................................................ 24 8.3 Transmission............................................... 27 8.4 Staging.................................................. 29 9 Setup 31 9.1 Overview................................................. 31 9.2 Bootstrapping.............................................. 38 9.3 Configuring a jailhost.......................................... 42 10 General usage 45 10.1 Managing jails.............................................. 45 10.2 Ansible integration............................................ 46 10.3 Fabric integration............................................. 48 10.4 Combining Ansible and Fabric...................................... 49 11 Special use cases 51 11.1 Staging.................................................. 51 11.2 Updating................................................. 53 i 11.3 Customizing bootstrap.......................................... 53 12 Contribute 55 13 License 57 14 TODO 59 ii bsdploy
    [Show full text]
  • ISO Types 1-6: Construction Code Descriptions
    ISO Types 1-6: Construction Code Descriptions ISO 1 – Frame (combustible walls and/or roof) Typically RMS Class 1 Wood frame walls, floors, and roof deck Brick Veneer, wood/hardiplank siding, stucco cladding Wood frame roof with wood decking and typical roof covers below: *Shingles *Clay/concrete tiles *BUR (built up roof with gravel or modified bitumen) *Single-ply membrane *Less Likely metal sheathing covering *May be gable, hip, flat or combination of geometries Roof anchorage *Toe nailed *Clips *Single Wraps *Double Wraps Examples: Primarily Habitational, max 3-4 stories ISO 2 – Joisted Masonry (JM) (noncombustible masonry walls with wood frame roof) Typically RMS Class 2 Concrete block, masonry, or reinforced masonry load bearing exterior walls *if reported as CB walls only, verify if wood frame (ISO 2) or steel/noncombustible frame roof (ISO 4) *verify if wood frame walls (Frame ISO 1) or wood framing in roof only (JM ISO 2) Stucco, brick veneer, painted CB, or EIFS exterior cladding Floors in multi-story buildings are wood framed/wood deck or can be concrete on wood or steel deck. Wood frame roof with wood decking and typical roof covers below: *Shingles *Clay/concrete tiles *BUR (built up roof with gravel or modified bitumen) *Single-ply membrane *Less Likely metal sheathing covering *May be gable, hip, flat or combination of geometries Roof anchorage *Toe nailed *Clips *Single Wraps *Double Wraps Examples: Primarily Habitational, small office/retail, max 3-4 stories If “tunnel form” construction meaning there is a concrete deck above the top floor ceiling with wood frame roof over the top concrete deck, this will react to wind forces much the same way as typical JM construction.
    [Show full text]
  • Graph Databases
    Graph databases Iztok Savnik, Famnit, UP Joint project with: Kiyoshi Nitta, Yahoo Japan Research Maj, 2016. 1 Outline 1) Graph data model (RDF) 2) Popular graph databases on Web 3) Big3store Graph data model (RDF + RDFS) Graph data model ● Graph database – Database that uses graphs for the representation of data and queries ● Vertexes – Represent things, persons, concepts, classes, ... ● Arcs – Represent properties, relationships, associations, ... – Arcs have labels ! RDF ● Resource Description Framework – Tim Berners Lee, 1998-2009 – This is movement ! ● What is behind ? – Graphs – Triples (3) – Semantic data models – Human associative memory (psychology) – Associative neural networks – Hopfield Network RDF RDF syntax ● N3, TVS ● Turtle ● TriG ● N-Triples ● RDF/XML ● RDF/JSON 7 Name spaces ● Using short names for URL-s – Long names are tedious ● Simple but strong concept ● Defining name space: prefix rdf:, namespace URI: http://www.w3.org/1999/02/22-rdf-syntax-ns# prefix rdfs:, namespace URI: http://www.w3.org/2000/01/rdf-schema# prefix dc:, namespace URI: http://purl.org/dc/elements/1.1/ prefix owl:, namespace URI: http://www.w3.org/2002/07/owl# prefix ex:, namespace URI: http://www.example.org/ (or http://www.example.com/) prefix xsd:, namespace URI: http://www.w3.org/2001/XMLSchema# 8 N-Triples <http://example.org/bob#me> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> . <http://example.org/bob#me> <http://xmlns.com/foaf/0.1/knows> <http://example.org/alice#me> . <http://example.org/bob#me> <http://schema.org/birthDate> "1990-07-04"^^<http://www.w3.org/2001/XMLSchema#date> .
    [Show full text]
  • [Pdf] ISO Cleanroom Standards and Federal Standard
    FS209E and ISO Cleanroom Standards Terra Universal is the leading expert in the design and fabrication of critical-environment applications. We offer a complete range of equipment, furnishing and supplies for cleanroooms and laboratories. Following are the rigorous standards to which Terra Universal adheres. Before global cleanroom classifications and standards were adopted by the International Standards Organization (ISO), the U.S. General Service Administration’s standards (known as FS209E) were applied virtually worldwide. However, as the need for international standards grew, the ISO established a technical committee and several working groups to delineate its own set of standards. FS209E contains six classes, while the ISO 14644-1 classification system adds two cleaner standards and one dirtier standard (see chart below). The “cleanest” cleanroom in FS209E is referred to as Class 1; the “dirtiest” cleanroom is a class 100,000. ISO cleanroom classifications are rated according to how much particulate of specific sizes exist per cubic meter (see second chart). The “cleanest” cleanroom is a class 1 and the “dirtiest” a class 9. ISO class 3 is approximately equal to FS209E class 1, while ISO class 8 approximately equals FS209E class 100,000. By law, Federal Standard 209E can be superseded by new international standards. It is expected that 209E will be used in some industries over the next five years, but that eventually it will be replaced internationally by ISO 14644-1. Before global cleanroom classifications and standards were adopted by the International Standards Organization (ISO), the U.S. General Service Administration’s standards (known as FS209E) were applied virtually worldwide.
    [Show full text]