Europeana原来的元数据方案称为《Europeana语义元素》（Europeana Semantic Elements, ESE），基于都柏林核心（DC），将不同来源、不同格式的元数据都简化到DC这个“公分母”，其结果是源数据中原有精确信息的损失。为改变这种状况，Europeana设计了开放、跨领域、基于语义网框架的《Europeana数据模型》（Europeana Data Model, EDM）。
《Europeana数据模型入门》（摘译【理解】）
来源：Europeana Data Model (EDM) Documentation
（原文中有较多RDF图，说明采用EDM对物件进行的语义描述）
1 导论
1.3 EDM准则
区分提供者提交的智力与技术创作（关于提供者保管的一个物件的资源包[元数据]）、其涉及的物件、以及可通过Web获取的该物件的数字表达。
遵循支持数据网（语义网）方法的建模原则，即没有一种固定模式只提供一种表达数据方法。EDM为通用模型，至少可在语义层部分互操作，同时数据保持其原来的表达性与丰富度。它不要求改变本地方法，尽管鼓励改变本地实践以改善数据的跨领域有用性，如采用公共获取词表（对个人、地点、主题等）。
1.4 如何阅读
URI涉及的命名空间：【2015-2-8更新：以下URI应当只是示例。根据Definition of the Europeana Data Model v5.2.4，EMD未用FOAF/VIAF/rdaGr2】
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix dc: <http://purl.org/dc/elements/1.1> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix ore: <http://www.openarchives.org/ore/terms/> .
@prefix edm: <http://www.europeana.eu/schemas/edm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix viaf: <http://viaf.org/viaf/> .
@prefix rdaGr2: <http://RDVocab.info/ElementsGr2/> .
2 EDM需求与设计原则提示
需求：
– R1. 区分被提供的物件与其数字表达
– R2. 区分物件与描述物件的元数据记录
– R3. 同一物件允许有多条记录，包含对物件潜在冲突的说明【因为记录可能有多个来源】
– R4. 支持由其他物件组成的物件【物件分层】
– R5. 兼容不同抽象度的描述（如遵循FRBR第一组的区分）【描述分层】
– R6. 提供可被专门化的标准元数据格式
– R7. 支持情景资源，包括来自受控词表的概念
基本动机是支持不同模型的集成，这样就可以收集并通过较高层概念关联所有原始描述。三项基本设计原则：
– D1. 允许在开放环境中集成数据：不可能预期所有贡献的数据【即不强制提供的数据格式一致】
– D2. 允许丰富功能性，可能通过扩展方式
– D3. 尽可能重用现有（标准）模型
4 数据表达为集合体（aggregation）
三个核心类资源：
• 文化遗产物件本身（edm:ProvidedCHO）【即“作品”】
• 该物件的一个或多个可访问的数字表达（edm:WebResource）某些可能被用作预览图【edm:hasView】
• 表达提供者活动结果的集合体（ore:Aggregation）【“真实的”物件（由其标识表达）与其数字视图之集合】
edm:aggregatedCHO和edm:hasView为ore:Aggregation的子属性。
5 EDM中的描述元数据
EDM包括一套“描述”和“情境”属性，捕捉资源的不同特性，同时在其情境中与其他实体关联。
描述元数据的可能方法可分为“物件中心”和“事件中心”，EDM同时遵循这两种方法。EDM还有“类”可抓取“丰富数据”。
5.1 物件中心法（Object-centric approach）
专注于所描述的物件：信息以陈述形式，直接关联所描述的物件与其特性——但只是字符串或是指示来自真实世界实体的更复杂资源。采用都柏林核心的大多数元数据实践属此（如创作者、题名、创作日期、前拥有者等）。
物件中心法对附于物件或事件的资源，并不指明特定的“语义丰富性”级别。
5.2 情景实体-更丰富的元数据（Contextual entities – richer metadata）【类】
描述元数据的某些值不关联到物件，而是关联到描述中的另一资源。如有关创作者的进一步细节——如其生卒地点与日期。在EDM中，这样的信息可使用表达创作者本人的实体来捕获。为支持对此种语义丰富的建模，并支持进一步丰富，EDM具有表达“情景”实体的“类”：
– edm:Agent 代理，用于代表个人或组织
– edm:Event 事件
– edm:Place 地点，用于空间实体
– edm:TimeSpan 时间范围，用于时间段或日期
– skos:Concept 概念，对来自如叙词表、分类法（包括某些地名辞典或个人规范档）……的知识组织体系的所有实体
5.3 事件中心法（Event-centric approach）
事件中心法认为物件描述应当关注描绘物件参与的不同事件，通过表达构成物件历史的事件，将导致建立更丰富的实体网络。此法基于CIDOC-CRM模型。
在EDM中使用三个属性表达：
– edm:wasPresentAt 参与事件的资源
– edm:happenedAt 事件发生的场所
– edm:occurredAt 事件与发生的时段
5.4 灵活的数据模型（EDM as a flexible data model）
确保语义层互操作的关键是映射，遵循语义网框架内的共同实践。
需要把专指属性映射到一个语义互操作核心，确保通用工具能利用至少部分语义。这种映射在RDF中典型地通过维护专指构建与核心构建间的语义关系来达到。
通用与专指层间的同现，允许如：
– 使用基于通用描述的索引搜索该物件【粗放索引】
– 使用由提供者制作的更精细度区别显示该物件的信息【精细显示】
这一机制事实上已经在EDM不同层的描述数据中起作用。如hasMet是指EDM中重用很多其他属性的超属性【可用于合并索引】，如创作者、贡献者、出版者。本属性将允许用户发现与某个人相关的物件，无论他们“遇到”的这个人是其主要的创作者、第二位的贡献者或是出版者。
5.5 ESE和EDM间关系
ESE所用大部分属性（DC属性）实际上构成EDM的语义互操作核心。
第一个差别是属性的使用。为兼容遗留数据及未丰富方式的数据，ESE/DC属性可用简单字符串作为值。但EDM推荐图8中首先引入的VIAF例子【即采用URI或ID】。
ESE和EDM利用同一属性方式的另一个差别是“一对一原则”的应用。ESE中，所有字段捆绑为一个记录，因之难以区分某个字段是应用于“真实世界”的物件、还是其数字表达、还是与该物件相关的任何其他实体的属性，如其创作者。而EDM允许做这种区分。
6 EDM和代理（proxies）
Europeana数据来自许多提供者，因而会有对同一资源的多个视图；此外，Europeana将试图增加对该资源的其自己数据，给出另一个视图。这些视图不会合并。在这种场合，元数据很可能不同，如同一创作者用不同名称。Europeana考虑来自ORE（对象重用与交换）模型的代理机制，可以在集合情景下表达资源，使得对同一资源有不同的视图。
6.1 代理导论
以《蒙娜丽莎》为例，有两条不同来源的记录。每个传递给Europeana的数据产生一个ore:Aggregation类的特定实例，用于组合来自同一个提供者的一个资源的所有元素。每个提供者贡献不同的数字对象集，有不同的解析度、不同的文件类型、不同的位置。
每个提供给Europeana的元数据记录也给出了所描述物件的专指代理，使用ore:Proxy资源建模。一个代理特定于一个给定的集合体，用于表达所提供物件的描述。通过代理，可能表达对所提供物件以不同的、可能冲突的信息，同时仍能追踪信息的出处。如两处《蒙娜丽莎》有不同的题名。
一个集合体对每个提供物件（CHO）只能有一个代理，因为它来自一个提供者的活动。
现阶段，如何、何时识别相同物件仍有讨论余地。如两个提供者为相同资源贡献了两个不同的URI，应采用某些识别机制在两个URI间推出owl:sameAs链接，以能“合并”资源。
6.2 Europeana代理和丰富数据（data enrichment）
Europeana为摄入的物件创建新数据，以期为用户提供更多价值。通过使用ESE格式处理标准化数据，用链接到情景实体在（词表、地名/人名规范档、主题词表）语义上丰富物件描述。这导致更丰富的功能，如提问扩展（使用创作者名称的交替形式）、使用语义关系推荐物件（关联艺术家创作的物件）等。这是关键方面，Europeana试图大规模处理这样的语义丰富，使用EDM为特定目的导入的类。
6.3 Europeana集合体和代理
Europeana集合体edm:EuropeanaAggregation是ore:Aggregation的子类，可以用来管理自己的IPR和访问限制等。
Europeana集合体采用ore:aggregates链接到所提供物件，也能集合其他资源，尤其是物件的数字表达，或使用edm:landingPage属性到其参考着陆页。关键一点是，Europeana集合体是集合关于相同物件的每个特定提供者的集合。
6.5 提供者应当提供EDM核心模式的什么部分？
期望来自提供者的最重要信息之一是区分物件本身的元数据和数字表达的元数据。
下一个问题涉及为不同物件提供URI标识符。第一个建议是提供者为网络可访问数字表达（如图片）和所提供的物件或已有永久标识的集合体提交URI。Europeana本身会注意为它创建的代理或集合体赋予或再赋予URI，它也会为所有edm:ProvidedCHO资源创建URI。【提供者和Europeana各自提供URI】
6.6 代理vs命名图（named graphs）
对于做EDM原型时，我们经常被问到为什么考虑ORE代理来表达特定资源视图，而RDF提供“命名图”的概念满足相同需求。因为命名图目前还非W3C推荐标准，但图的概念将出现在下一版RDF，到那时，Europeana当然将考虑将图放入EDM架构中。
7 高级EDM
EDM允许更复杂的表达，特别关注以下情况：
– 物件的等级
– 物件间关系，如表达作品间关系或艺术衍生
– 通过ORE资源地图明确表达数据包
本文件只表达简单的等级物件及表达链接。其他方面在未来版本详述
7.1 表达等级物件
以一幅来自荷兰的地图为例
– 用dcterms:hasPart and dcterms:isPartOf 表达包含链接
– 用edm:isNextInSequence表示物件各部分间的顺序
代理机制允许对相同物件配置多个等级视图。
7.2 物件间其他链接类型
– 两个物件描画同一地点巨石阵：
直接关联两幅图片，让用户从一个物件浏览另一个，采用Europeana目前带有十分精确信息的“进一步探索”功能，依赖于手头数据的精确程度，使用通用属性edm:isRelatedTo或（可能领域专用的）专用属性。
也可能非直接关联物件，通过说明其链接到相同资源。比如由空间覆盖判断为巨石阵（地点）
– 第二个例子是《蒙娜丽莎》的衍生作品-拼贴画，采用edm:isRelatedTo的子属性edm:isSimilarTo的专门edm:isDerivativeOf属性
Europeana还收割了一条描述《蒙娜丽莎》照片的记录，是19世纪法国摄影师所摄，采用edm:isRepresentationOf，说明这一历史图片与原画的关联
———译名说明———
（1）object=物件（正好与模型中提到的“event=事件”对应）
不采用“实物”：因为有digital object，译为“数字实物”比较奇怪，参考台湾译为“数位物件”
不采用“对象”：适应面太广、专指性不强，如“研究对象”
（2）contextual=情景
不采用“上下文”：大多数情况下并不涉及“文字”