GB/T 32392.2-2015 信息技术 互操作性元模型框架（MFI） 第2部分：核心模型
- 名 称：GB/T 32392.2-2015 信息技术 互操作性元模型框架（MFI） 第2部分：核心模型 - 下载地址2
- 下载地址：[下载地址2]
- 提 取 码：
- 浏览次数：3
发表评论 加入收藏夹 错误报告目录| 新闻评论（共有 0 条评论） |
资料介绍
ICS 35. 040 L 72
中 华 人 民 共 和 国 国 家 标 准
GB/T 32392.2—2015
信息技术 互操作性元模型框架(MFI)
第 2 部分 :核心模型
Information technology—Metamodelframework forinteroperability(MFI) —
Part2:Coremodel
2015-12-31发布 2017-01-01实施
中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会
发
布
GB/T 32392.2—2015
前 言
GB/T 32392《信息技术 互操作性元模型框架(MFI)》包含以下几个部分 :
— 第 1部分 :参考模型 ;
— 第 2部分 :核心模型 ;
— 第 3部分 :本体注册元模型 ;
— 第 4部分 :模型映射元模型 ;
— 第 5部分 :模型构件六模型框架 ;
— 第 6部分 :注册规程 。
本部分按照 GB/T 1. 1—2009给出的规则起草 。
本部分为 GB/T 32392的第 2部分 。本部分参考国际标准最终委员会草案 ISO/IEC FCD 19763- 2:2007版编制 。
请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别这些专利的责任 。
本部分由全国信息技术标准化技术委员会(SAC/TC28)提出并归 口 。
本部分起草单位 :武汉大学软件工程国家重点实验室 、中国电子技术标准化研究院 。
本部分主要起草人 :何克清 、何扬帆 、王翀 、王健 、王静 。
GB/T 32392.2—2015
引
言
随着电子业务和电子商务在因特网的广泛传播 ,跨国家和跨文化的业务贸易和其他相关信息交换已成为 IT业内外人员主要关注的问题 。他们致力于规范代表业务实践的领域特定业务过程模型和标准建模结构 ,如每个业务域的数据元素 、实体轮廓和值域等 。标准化的工作主要关注模型或者元模型的内容 ,使用 UML和 XML表示和交换业务的语义 。
标准化活动推动了元模 型 和 UML 轮 廓 的 发 展 , 这 些 活 动 包 括 联 合 国 贸 易 促 进 和 电 子 商 务 中 心(UN/CEFACT) 、结构化信息标准促进组织(OASIS) 、对象管理组(OMG)和卫生 7 级(HL7) 标准 。然而 ,不同的标准组织都按照自己的方式规定元模型模式 。 因此 ,需要为元模型的一致性开发和注册规定公共的基础 ,否则有可能产生重复和不一致 。
用于分类和注册规范化模型元素的统一框架对建立独立开发的元模型的协调性来说是一个重要部分 ,并且能够促进它们在组织间的广泛重用 。
元模型和模型能够描述可以共享的业务概念和部件 , 以支持系统之间的互操作 。
因特网应用的发展使得信息共享变得越来越重要 。然而 ,对于真实的信息来说 ,不同的开发者 、不同的用户和不同的视角都会赋予其不同的解释 。仅通过单词分类对信息进行整理是比较困难的 。我们将这些本质复杂的信息整理成一个系统化的信息世界 ,并建议 MFI能够通过信息注册来提高信息的共享和兼容性 。本部分为解决这个领域的问题提供了帮助 。
信息技术 互操作性元模型框架(MFI)
第 2 部分 :核心模型
1 范围
GB/T 32392的本部分提供了核心模型 。该核心模型将在 GB/T 32392 的其他部分得到应用 。核心模型规定了为注册其他元模型和模型的规范化 MFI元模型 。
特定业务域中注册的业务概念和业务模型的标准化不在本部分的范围之内 。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的 。凡是注 日期的引用文件 ,仅注 日期的版本适用于本文件 。凡是不注日期的引用文件 ,其最新版本(包括所有的修改单)适用于本文件 。
GB/T 18391. 6—2009 信息技术 元数据注册系统 (MDR) 第 6 部分 : 注册(ISO/IEC 11179- 6:2005, IDT)
GB/T 32392. 3—2015 信 息 技 术 互 操 作 性 元 模 型 框 架 (MFI) 第 3 部 分 : 本 体 注 册 元 模 型
(ISO/IEC 19763-3:2007, IDT)
GB/T 32392. 4—2015 信息技术 互操作性元模型框架(MFI) 第 4部分 :模型映射元模型ISO/IEC 19501:2005 信息技术 开放分布式处理 统一建模语言
ISO/IEC 19502:2005 信息技术 元对象设施
ISO/IEC 20944 信息技术 元数据注册系统互操作性和绑定
3 术语、定义和缩略语
下列术语 、定义和缩略语适用于本文件 。
注 : 3. 1定义了本部 分 使 用 的 统 一 建 模 语 言 UML(ISO/IEC 19501: 2005) 和 元 对 象 设 施 MOF(ISO/IEC 19502:
2005)中的术语 。3. 2列出了本部分使用但未包含在 3. 1 中的术语及其定义 。
3. 1 本部分使用的 UML和 MOF术语
3. 1. 1
抽象 abstraction
使实体区别于其他实体的本质特性 。
注 : 抽象定义了观察者视角的边界 。
3. 1.2
抽象句法 abstractsyntax
UML类图中用以定义构件及其相互关系的元类 。
3. 1.3
制品 artefact
软件开发过程中产生的一种物理形式的信息 。
注 : 写制品可以用于实现可部署的部件 。
示例 :
文件 、脚本和二进制可执行文件 。
3. 1.4
关联 association
两个或多个类元素之间的语义关系 ,规定了类元素实例之间的连接 。
3. 1.5
关联端点 association end
关联的端点 ,连接关联与类元素 。
3. 1.6
属性 attribute
MOF建模中类元素的特征 ,描述了类元素实例的取值范围 。
3. 1.7
属性 attribute
对象或实体的元模型特性 。
3. 1. 8
绑定 binding
通过为模板参数赋值的方式来创建基于模板的模型元素 。
3. 1.9
势 cardinality
集合中元素的个数 。
对比 :多重度(3. 1. 44) 。
3. 1. 10
类 class
对一个对象集合的描述 。这些对象共享相同的属性 、操作 、方法 、关系和语义 。
类可以使用接口集来说明它提供给环境的操作集合 。
3. 1. 11
类元素 classifier
行为和结构特征的描述机制 。类元素包括接口 、类 、数据类型和部件 。
3. 1. 12
分类 classification
将一个对象赋给一个特定的类元素 。
3. 1. 13
类图 classdiagram
说明声明性(静态的)模型元素(如类和类型)及其相互关系的图 。
3. 1. 14
协作图 collaboration diagram
描述围绕一个模型结构所展开的交互的图 。 图中使用类元素和关联 ,或实例和链接 。
3. 1. 15
部件 component
系统的模块化 、可配置的 、可替换的部分 。部件封装了实现部分 ,对外提供一组接 口 。
注 : 部件通常由一个或多个驻留在其中的类元素(如实现类)进行规约 ,可以通过一个或多个制品(如二进制可执行文件或脚本文件)来实现 。
3. 1. 16
组合 composition
一种特定形式的聚合 。要求部分的实例包含在至多一个组合的实例中 。组合对象负责各个部分的创建和销毁 。
注 : 组合可以是递归的 。
3. 1. 17
约束 constraint
语义条件或限制 。有些约束是 UML预先定义的 ,其他的可以由用户定义 。
对比 :标签值(3. 1. 65)和构造型(3. 1. 60) 。
注 : 约束是 UML提供的 3 种可扩展机制之 一 。
3. 1. 18
容器 container
,一个包含其他实例的实例 ,提供了访问和迭代其内容的操作 。
示例 :
数组 、链表和集合 。
3. 1. 19
容器 container
一个包含其他部件的部件 。
3. 1.20
语境 context
出于特定目的(如规定对操作)从特定角度观察一组相关的建模元素 。
3. 1.21
数据类型 datatype
一组值的描述符 。这些值没有单独的标识 。值的操作不具副作用 。
注 : 数据类型包括基本的 、预先定义的类型和用户定义的类型 。预先定义的类型包括数字型 、串型和时间型 。用户定义的类型包括可枚举型 。
3. 1.22
依赖 dependency
建模元素间的一种关系 ,如果改变其中一个建模元素(独立元素)将影响另外一个(依赖元素) 。
3. 1.23
图(示) diagram
一组建模元素的图形化表示 ,通常表现为弧(关系)和顶点(其他的某些元素)的连接图 。
注 : UML支持下列图示 :类图 、对象图 、用例图 、顺序图 、协作图 、状态图 、活动图 、部件图和部署图 。
3. 1.24
(领)域 domain
由特定的知识或活动构成的论域 , 由一组能被该领域的从业者理解的概念和术语所刻画 。
3. 1.25
元素 element
模型的原子组成成分 。
3. 1.26
特征 feature
封装在类元素(如接口 、类和数据类型)中的特性 ,如操作或属性 。
3. 1.27
框架 framework
,一个包含模型元素的构造型包 。 这些模型元素为系统的全部或部分定义了一个可重用的架构 。
注 : 典型的框架包括类 、模式或模板 。在针对特定应用域进行特化后 ,框架通常被称为应用框架 。
对比 :模式(3. 1. 52) 。
3. 1.28
可泛化元素 generalizableelement
泛化关系中的模型元素 。
3. 1.29
泛化 generalization
一般元素和具体元素之间的分类学关系 。具体元素与一般元素保持一致 ,并包含额外的信息 。具体元素的实例可以在一般元素适用的任何地方使用 。
对比 :继承(3. 1. 30) 。
3. 1.30
继承 inheritance
为更具体元素赋予更一般元素所具有的结构和行为的机制 。
对比 :泛化(3. 1. 29) 。
3. 1.31
实例 instance
一种特殊的实体 ,具有唯一标识符 、一组可以应用其上的操作以及用以存放操作效果的状态 。
对比 :对象(3. 1. 47) 。
3. 1.32
层 layer
相同抽象层上的类元素或包的一种组织形式 。层代表体系结构的水平切面 , 而划分代表体系结构的垂直切面 。
对比 :划分(3. 1. 51) 。
3. 1.33
链接 link
对象间的语义关联 ,是关联的实例 。
对比 :关联(3. 1. 4) 。
3. 1.34
链接端点 link end
关联端点的实例 。
对比 :关联端点(3. 1. 5) 。
3. 1.35
元类 metaclass
实例仍为类的类 。元类通常用以构成元模型 。
3. 1.36
元元模型 meta-metamodel
定义元模型语言的模型 。
注 : 元元模型与元模型的关系类似于元模型和模型的关系 。
3. 1.37
元模型 metamodel
定义模型语言的模型 。
3. 1.38
元模型 metamodel
定义其他数据模型的数据模型 。
3. 1.39
元对象 metaobject
元建模语言中所有元实体的统称 。
示例 :
元类型 、元类 、元属性和元关联 。
3. 1.40
模型 model
针对特定目的对物理系统建立的一种抽象 。
注 : 在描述元元模型的 MOF规范中 ,为便于描述 ,元元模型经常被简单记做模型 。
3. 1.41
模型元素 modelelement
从待建模系统中抽象出的元素 。
对比 :视图元素(3. 1. 68) 。
注 : 在 MOF规范中 ,模型元素被看作元对象 。
3. 1.42
元对象设施 MetaObjectFacility;MOF
用以描述元模型的公共设施 。
3. 1.43
遵循 MOF的 MOF compliant
基于 MOF的 MOF based
基于 MOF模型描述的 。
3. 1.44
多重度 multiplicity
规定了集合可以容许的势的范围 。
注 1:多重度可用于描述关联的角色 、组合的部分等 。
注 2: 多重度实质上是非负整数的(有可能是无限的)子集 。
3. 1.45
(模型元素的)名称 name(ofmodelelement)
MOF建模中用以识别模型元素的字符串 。
3. 1.46
名称空间 namespace
MOF建模中模型的一个组成部分 ,用以定义名称 。
注 : 在名称空间中 ,每个名称有唯一的含义 。
对比 : (模型元素的)名称(3. 1. 45) 。
3. 1.47
对象 object
MOF建模中封装了状态和行为的实体 ,具有定义良好的边界和特性 。
注 1:状态由属性和关系表示 ,行为由操作 、方法和状态机表示 。
注 2:对象是类的实例 。
对比 :类(3. 1. 10)和实例(3. 1. 31) 。
3. 1.48
操作 operation
对象可以提供的服务 ,该服务能够产生一定的影响 。
注 : 操作有相应的接 口 ,用以限制可能的实际参数 。
3. 1.49
包 package
对元素进行组织的常用机制 。
注 : 包可以嵌套在其他包中 。
3. 1.50
参数化元素 parameterized element
模板 template
含有一个或多个自由参数的类描述符 。
3. 1.51
划分 partition
处于某层次化体系结构中相同抽象层次或者跨层次的一组相关类元素或者包 。
注 : 划分代表体系结构的垂直切面 ,而层则代表水平切面 。
对比 :层(3. 1. 32) 。
3. 1.52
模式 pattern
模板化的协作 。
3. 1.53
轮廓 profile
需要指定的所依赖的模型库以及所扩展的元模型子集 。
注 : 构造型化的包由使用构造型 、标签值和约束等扩展机制得到的模型元素组成 。这些元素服务于特定的域或者目的 。
3. 1.54
性质 property
,表达元素特性名称的值 ,性质有语义影响 。
注 : 部分性质由 UML预先定义 ;其他的可由用户定义 。
3. 1.55
参考/指针 reference/pointer
,一种模型元素的指称方式 。
3. 1.56
参考/指针 reference/pointer
,类元素中名称的槽 ,用以导航到其他类元素 。
3. 1.57
关系 relationship
模型元素间的语义连接 。
示例 :
关联和泛化 。
3. 1.58
存储库 repository
存储对象模型 、接口和具体实现的机制 。
3. 1.59
角色 role
特定语境中实体的命名行为 。
注 : 角色可以是静态的(如关联端点)或者动态的(如合作角色) 。
3. 1.60
构造型 stereotype
扩充了元模型语义的新型建模元素 。
注 1: 构造型必须基于元模型中已有的类型或类 。
注 2: 构造型可以扩展已有类型和类的语义而不是其结构 。
注 3: 一些构造型预先在 UML 中给出了定义 ,其他的则由用户定义 。
注 4: 构造型是 UML提供的 3 种扩展机制之 一 。
对比 :约束(3. 1. 17)和标签值(3. 1. 65) 。
3. 1.61
子类 subclass
泛化关系中超类的具体化 。
对比 :泛化(3. 1. 29)和超类(3. 1. 63) 。
3. 1.62
子类型 subtype
在泛化关系中超类型的具体化 。
对比 1:泛化(3. 1. 29) 。
对比 2:超类型(3. 1. 64) 。
3. 1.63
超类 superclass
在泛化关系中子类的泛化 。
对比 1:泛化(3. 1. 29) 。
对比 2:子类(3. 1. 61) 。
3. 1.64
超类型 supertype
在泛化关系中子类型的泛化 。
对比 1:泛化(3. 1. 29) 。
对比 2:子类(3. 1. 61) 。
3. 1.65
标签值 tagged value
将性质显式地定义为名称-取值对 。在标签值中 ,名称被称为标签 。
注 : 某些标签在 UML 中预先给出了定义 ,其他的则由用户定义 。标签值是 UML提供的 3 种扩展机制之 一 。
对比 :约束(3. 1. 17)和构造型(3. 1. 60) 。
3. 1.66
类型 type
类的一种构造型 ,用以指定实例域(或对象域)以及实例(对象)上可以实施的操作 。注 : 类型可以不包括任何方法 。
对比 :类(3. 1. 10)和实例(3. 1. 31) 。
3. 1.67
视图 view
模型的投影 ,从给定的视图或有利位置观察所得 ,忽略了与该视图不相关的实体 。
3. 1.68
视图元素 view element
一组模型元素的文本化或图形化的投影 。
3. 1.69
XML 元数据交换 XML metadata interchange;XMI
由遵循 MOF的模型生成的 XML模式 。
3.2 本部分使用的通用术语
3.2. 1
管理项 administered item
管理记录中管理信息的注册系统项 。
3.2.2
特性 characteristic
对象或对象集的性质的抽象 。
注 : 特性用以描述概念 。
3.2.3
概念 concept
由唯一的特性组合创建或规定的知识单元 。
3.2.4
概念数据模型 conceptualdata model
表示现实世界抽象视图的数据模型 。
3.2.5
数据 data
信息的可重解释的表示 ,通常采用形式化方式进行描述 , 以便于交流 、解释或处理 。注 : 数据可以由人工或自动的方式进行处理 。
3.2.6
数据模型 data model
数据的图形化或词汇方式的表示 ,规定了它们的性质 、结构和相互之间的关系 。 3.2.7
定义 definition
通过描述性的语句来表达概念 , 以便将其与相关概念区分开来 。
3.2. 8
指定 designation
通过指代其记号得到的概念表示 。
3.2.9
实体 entity
任何存在的(包括确实存在和有可能存在)具体的或抽象的东西 ,包括实体之间的关联 。示例 :
人 、对象 、事件 、思想 、过程等 。
注 : 实体可以存在于可获得相关数据的地方 ,也可以存在于不可获得相关数据的地方 。
3.2. 10
语言 language
为了交流而建立的记号体系 ,通常包括词汇表和规则 。
3.2. 11
强制的 mandatory
总是必须的 。
注 1: 描述元数据项属性强制程度的三种状态之一 ,指出需要该属性的条件 。
注 2: 应用到元数据项上时 ,注册状态应该为 “已记录 ”或者更高 。
对比 :可选的(3. 2. 35) 。
3.2. 12
元数据 metadata
用以定义和描述其他数据的数据 。
3.2. 13
元数据项 metadata item
元数据对象的实例 。
注 1: 在 GB/T 32392 中 ,本术语仅适用于本部分第 4 章所描述的元数据对象 。
示例 :
模型概念 、模型域概要和模型部件集的实例 。
注 2: 元数据项有相关的属性 ,适用于它所实例化的元数据对象 。
3.2. 14
元数据对象 metadata object
元模型定义的对象类型 。
注 : 在 GB/T 32392 中 ,该术语仅适用于本部分中定义的元模型的元数据对象 。
示例 :
模型概念 、模型域轮廓和模型部件集等 。
3.2. 15
元数据注册库 metadata register
由元数据注册系统维护的信息存储库或数据库 。
3.2. 16
元数据注册系统 metadata registry;MDR
注册元数据的信息系统 。
注 : 相关的信息存储库或数据库称为元数据注册库 。
3.2. 17
模型记号 modelsign
指派名称空间中某个名称的元类 。
3.2. 18
模型概念 modelconcept
说明某个概念含义的元类 。
3.2. 19
模型类元素 modelclassifier
分类模型概念的元类 。
3.2.20
模型域轮廓 modeldomain profile
规定模型概念定义的语境的元类 。
3.2.21
模型部件 modelcomponent
规定注册元素的元类 。
3.2.22
模型部件集 modelcomponentset
规定注册元素集合的元类 。
3.2.23
模型选择 modelselection
用以说明选中的注册元素集合的元类 。
3.2.24
模型规范 modelspecification
规定域规范的文档的元类 。
3.2.25
模型构件 modelconstruct
规定建模构件的元类 。
3.2.26
遵循 MOF的模型 modelbyMOF
规定遵循 MOF规范的模型或元模型的元类 。
3.2.27
模型关联 modelassociation
规定模型类元素之间关联的元类 。
3.2.28
模型关联端点 modelassociation end
规定模型关联的端点的元类 。
3.2.29
建模参考 modeling reference
规定模型关联的相关信息的元类 。
3.2.30
建模构件 modeling construct
建模的记法单元 ,如 UML 中的命名元素 。
3.2.31
互操作性元模型框架 metamodelframework for interoperability;MFI
注册基于元模型和模型的制品的框架 。
3.2.32
对象名称 nameofobject
用语言表达式来指代一个对象 。
注 : 见管理项名称 (3. 2. 33) 。
3.2.33
管理项名称 nameofadministered item
在特定语境中指派给管理项的名称 。
注 1: 对应的元模型构件是 “指定的属性 ”
注 2: (模型元素的)名称(3. 1. 45) 。
3.2.34
对象 object
在元模型中 ,表示可以感知或想象的任何事物 。
注 : 对象可以是物质的(如一个发动机 、一片纸或一个钻石) 、非物质的(如变换比率或项 目方案) 或想象的(如独角兽) 。
3.2.35
可选的 optional
允许但非必须的 。
注 1: 元数据项属性强制程度的三种状态之一 ,指出需要该属性的条件 。
注 2: 应用到元数据项上时 ,注册状态应该为 “已记录 ”或更高 。
对比 :强制的(3. 2. 11) 。
3.2.36
注册机构 registration authority
负责维护注册库的组织 。
3.2.37
注册系统项 registryitem
元数据注册系统中记录的元数据项 。
3.2.38
注册系统元模型 registry metamodel
规定元数据注册系统的元模型 。
3.2.39
记号 sign
用特定语言或者标记来指示概念 。
3.2.40
统一资源标识符 uniform resource identifier;URI
用以标识资源(特别是因特网上的)的格式化串 。
注 : 其句法需遵循《因 特 网 资 源 定 位 符 的 功 能 建 议》[RFC 1736] 和《唯 一 资 源 名 称 的 功 能 要 求》[RFC 1737] 中 的建议 。
3.2.41
XML模式 XML schema
可扩展置标语言 XML 的模式定义语言 。
4 互操作性元模型框架(MFI)核心规范
4. 1 概述
本章描述了互操作性元模型框架 MFI核心所定义的模型 。MFI核心提供了一组建模元素以及它们的使用规则 ,根据这些规则可以注册模型 。
4. 1. 1 核心模型概述
本部分提供了一个基础设施 ,该设施能够有效促进电子商务中各企业共享合作所需的信息元素和业务模型 。本部分有助于实现独立开发的元模型和模型的共享 。本部分可以按照 MOF 的 4 层体系结构来描述 。MOF提 供 了 一 组 建 模 元 素 和 相 应 的 使 用 规 则 以 支 持 元 模 型 的 开 发 。 这 一 关 注 点 使 得MOF能够作为特定域的建模环境 ,为定义领域元模型提供支持 。MOF不是一个具有通用 目的的建模环境 。
4. 1. 1. 1 MFI的 4 层元数据体系结构
MFI的 4层元数据体系结构基于 ISO/IEC 19502:2005 中描述的传统的 4 层元数据体系结构 , 而ISO/IEC 19502:2005 中的框架又以 GB/T 16647—1996为基础 。
ISO/IEC 19502:2005 中描述的 4层元数据体系 、结构如下 :
a) 信息(对象)层(M0)的信息包含了用户希望描述的数据 。
b) 模型层(M1)包含了描述实例层数据的元数据 。元数据聚在一起形成了模型 。
c) 元模型层(M2)包含定义了元数据结构和语义的描述信息(即元元数据) 。元元数据聚在一起形成的元模型是一种抽象语言(即没有具体句法或者记法) ,可以用来描述不同类型的数据 。
d) 元元模型层(M3)包含描述元元数据结构和语义的描述信息 。换句话说 ,这是定义不同类型元数据的 “抽象语言 ”。
在本部分中 ,术语 “元模型 ”泛指模型和元模型 。UML是一种通用的建模语言 ,独立于特定的对象域或实现环境 。可以使用构造型 、标签值或约束来定义轮廓以实现对 UML语言的扩展 。UML轮廓可以在现有的元模型基础上规定 ,添加新的模型元素 。对于使用 UML轮廓描述的域而言 ,需要提供模型元素的构造型信息以清楚地表达模型的含义 。
图 1示出了域模型可以使用基于 MOF的建模构件(如模式或者构造型)来描述 。
例如 ,在电子商务消息交换中 ,各方交互所遵循的业务过程模型可以看做模型或者元模型 。在这种情况下 ,制品(如消息格式和协议)可以作为注册目标 。此外 ,概念和相应的实例(包括词汇表和分类)也可以使用核心模型进行注册 。
图 1 MFI的元数据体系结构和待注册的制品
4. 1. 1.2 互操作性元模型框架一览
本部分使用元模型来描述 MFI元数据注册库的结构 。MFI注册系统元模型是一个概念化模型 , 即描述现实世界中相关 信 息 如 何 组 织 的 模 型 。本 部 分 不 涉 及 任 何 实 现 模 型 。 然 而 , 实 现 应 该 严 格 遵 循MFI标准 , 以实现对元模型和相关模型的公共管理 。
在 MFI标准中 ,使用 MOF元数据体系结构层来制定框架的 目的是为了辅助定义元元模型中元素的含义及其相互之间的关系 。本部分对 MOF体系结构的 M3层进行了扩充以支持这些元素的注册 。
为便于描述 ,MFI中的模型被组织为以下 5个包 :
a) 遵循 MOF的 MDR:管理项(见附录 A) ;
b) 遵循 MOF的对象 :包中元素和名称的元素(参见附录 B) ;
c) 核心模型(见 4. 3、4. 4、4. 5 和参见附录 C 和附录 D) ;
d) 本体注册元模型(见 GB/T 32392. 3—2015) ;
e) 模型映射元模型(见 GB/T 32392. 4—2015) 。
如 图 2 所 示 , 核 心 模 型 包 含 5 个 包 , 分 别 描 述 目 标 、注 册 系 统 、关 系 、层 对 和 模 型 类 元 素 。 图 2中 未 标 上 阴 影 的 两 个 包 — 遵 循 MOF 的 对 象 包 和 遵 循 MOF 的 MDR 包 以 本 部 分 之 外 的 标 准(GB/T 18391和 ISO/IEC 19502: 2005) 为 基 础 。 此 图 描 述 了 这 些 包 与 MOF 的 4 层 体 系 结 构 之 间的对应关系 。
本部分的主要目的是实现建模制品的共享 。如图 2所示 ,核心模型位于 MOF体系结构之中 ,作为遵循 MOF的一个元模型 。遵循 MOF的其他元模型也可以置于 MOF体系结构之中 。从本部分的角度看 ,这些元模型仅仅被称作使用 MOF和 UML定义的部件 。
为便于描述 ,核心模型被组织为以下 5个包 :
a) 注册系统包(规范性的 ;见图 3 和 4. 3) ;
b) 目标包(规范性的 ;见图 4 和 4. 4) ;
c) 关系包(规范性的 ;见图 5 和 4. 5) ;
d) 模型类元素包(资料性的 ;参见附录 C) ;
e) 层对包(资料性的 ;参见附录 D) 。
本部分与 GB/T 32392. 1—2015的关系 :
GB/T 32392. 1—2015描述了整个标准的框架 ,包括本部分、GB/T 32392.3—2015和 GB/T 32392.4— 2015。本部分以 GB/T 32392. 1—2015为基础 。
本部分 、GB/T 32392. 3—2015和本体定义元模型(ODM)的关系 :
GB/T 32392. 3—2015为参考本体和本地本体规定了一个注册其 管 理 信 息 和 其 他 信 息 的 元 模 型 。本部分对 MOF进行了扩充 。GB/T 32392. 3—2015需要对本部分的一些内容(如模型概念 、模型域轮廓 、模型部件等)进行扩展 。 OMG 发布的 ODM 为本体描 述 语 言 规 定 了 一 个 与 MOF兼 容 的 元 模 型 。 ODM 与 GB/T 32392. 3—2015可以很好地结合起来 ,为本体注册提供支持 。
本部分与 GB/T 32392. 4—2015的关系 :
GB/T 32392. 4—2015对本部分做了扩充 , 以支持模型映射 。 可以使用遵循 MOF 的查询/视图/转换规范(QVT)来描述模型映射规则 。QVT可以与 GB/T 32392. 4—2015很好地协调 ,共同为模型映射与转换规则的注册提供支持 。
图 2 MFI核心包和目标模型
4. 1.2 核心模型的符号约定
核心模型的制定以 MOF和 MDR定义的管理项为基础 。使用的 MOF元模型构件包括类 、关系 、关联类 、属性和参考 。这些术语在 3. 1 中有相应的定义 ,其模型在附录 B有具体的描述 。
核心模型表示为一系列 UML类图 ,每个类按照如下方式进行描述 :
a) 超类
直接继承的类 。
b) 属性
属性名称 :数据类型和势 ,强制的或可选的
属性名称的内容及目的的描述 。
c) 参考
参考名称 :类名和势 ,强制的或者可选的 。
参考名称的内容及目的的描述 。
d) 约束
如果需要 ,可以使用自然语言来表达约束 。
模型示出了属性和参考的最小势及最大势 。最大势约束在所有时间内有效 , 而最小势约束仅在元数据项的注册状态为 “已记录 ”或者更高的情况下生效 。“已记录 ”或更高的注册状态在 GB/T 32392 中有详细的定义 。“已记录 ”表明 ,所有强制属性的值均已记录 。
4. 1.3 核心模型
图 3示出了核心模型的高层概览 。本部分规定了如下类型的管理项 。 图中的管理项在后文有详细描述 。下述管理项的记法示例参见附录 E:
— 模型记号(见 4. 2. 1) ;
— 模型概念(见 4. 2. 2) ;
— 模型部件集(见 4. 2. 3) ;
— 模型选择(见 4. 2. 4) ;
— 模型域轮廓(见 4. 3. 1) ;
— 模型部件(见 4. 3. 6) 。
此处的管理项符合 GB/T 32392的定义 。本部分中元对象的标识符具有唯一性 。
图 3 核心模型概述
4.2 注册系统包(注册系统的结构)
图 4示出了核心模型中注册包的基本结构 。
图 4 MFI核心的注册系统包
4.2. 1 模型记号
模型记号是一种元类 ,具有记号和名称空间 。该记号在名称空间中是唯一的 。模型记号实例能够辅助识别出特定的 、用户感兴趣的事物 ,如包 、类和关联 。模型记号由相关的模型概念作出规约 ,可以用来表达多个模型选择 。模型记号是一种管理项 。
每个类按照如下方式进行描述 :
a) 超类
管理项 (源自 MDR) 。
b) 属性
名称空间 : 串型[1. . 1] ,强制的
用于识别唯一定义了该记号的名称空间的串 。
记号 : 串型 [1. . 1] ,强制的
用于识别引发模型概念的命名元素的串 。
c) 参考
指派 :模型概念[1. . 1] ,强制的
提供了一个指向模型概念的指针 ,模型记号的含义由该模型概念规定 。
d) 约束
表达 :模型选择[0. . * ] ,可选的
模型选择由模型记号表达 。
名称空间需遵循该空间所处的特定环境(如 MOF、XML等)的规则 。在注册 XML元素名称时 ,需使用 XML名称空间 。在注册 MOF模型元素时 ,要使用包的名称 。但是 ,也可以使用全局唯一标识符 ,如 URI。
名称空间由用户社区中的注册机构负责管理和维护 。
模型记号实例包括从其超类(管理项)继承而来的名称 ,在注册时应该遵循管理项语言部分的规定 。
4.2.2 模型概念
模型概念是一个具有模型类型的元类 。模型概念由模型域轮廓作出规约 ,依据模型类元素进行分类 。模型概念是一种管理项 。
模型概念建立了被模型类元素分类的概念和模型域轮廓提供的语境之间的关联 。
每个类按照如下方式进行描述 :
a) 超类
管理项(源自 MDR) 。
b) 属性
模型类型 :类型代码[1. . 1] ,强制的
代码可以用于区分模型类元素的不同类型 。表 1 提供了一组预先定义的模型类型 。
c) 参考
由 . . . 规定 :模型域轮廓[0. . * ] ,强制的
提供模型概念语境的模型域轮廓 。
概念 : 模型类元素[0. . 1] ,可选的
对模型概念进行分类的模型类元素 。
d) 约束
由…指派 : 模型记号[0. . * ] , 可选的
概念化 : 模型部件集[0. . * ] ,可选的
模型类元素及其代码系统应该使用相同的模型域轮廓 。
模型概念实例包括从其超类 — 管理项继承的名称 ,在注册时都应该遵循管理项语言部分的规定 。模型概念由用户社区中的注册机构负责管理和维护 。
表 1 模型类型的代码集(资料性的)
4.2.3 模型部件集
模型部件集是一种具有概念类型 、部件类型和格式信息的元类 。模型部件集由一组部件组成 ,可以由模型概念加以概念化 。
使用模型记号指派特定的模型概念 ,可以指代相应的模型部件集 。模型部件集可以按照模型类元素进行分类 。概念化类型指定了模型类元素和模型部件的关联 。模型部件集是一种管理项 。
每个类按照如下方式进行描述 :
a) 超类
管理项(源自 MDR) 。
b) 属性
概念化类型 : 类型代码[1. . 1] ,强制的
概念化类型定义了被包含的模型部件和标识为 “概念化为某个模型 ”的模型类元素之间有可能存在的关系 。表 2列举了 4种预先定义的概念化类型 。允许对该表进行扩充 。
部件类型 : 类型代码 [1. . 1] ,强制的
代码表示了模型部件的类型 。
不同的标准开发组织颁布了多种部件类型 。部件类型代码集由 MFI注册系 统 负 责 注 册 与 管 理 。表 G. 1列出了一些可选的部件类型 。
格式 : 串型[1. . 1] ,强制的
用以识别模型部件格式的串 。允许的格式(如 XML模式)应该在 MFI注册系统中进行注册和管理。
c) 参考
被…概念化 : 模型概念[0. . 1] ,强制的
模型概念为模型部件集提供了概念化 。
拥有 : 模型部件[0. . * ] ,强制的
模型部件集中包含的模型部件 。
d) 约束
被…选择 : 模型选择[0. . * ] ,可选的
模型部件集包含一组由模型类元素得到的模型部件 。
部件类型和代码系统应该遵循相应的模型域轮廓 。
模型部件集实例包括从其超类 — 管理项继承的名称 ,在注册时应该遵循管理项语言部分的规定 。模型部件集由用户社区中的注册机构负责管理和维护 。
表 2 概念化类型的代码集
4.2.4 模型选择
模型选择是一个具有选择条件的元类 。模型选择选定了一个模型部件集 ,使用模型记号来表达 。模型选择代表了模型记号和模型部件集之间的链接 。
根据模型部件集的条件 ,可以访问由模型部件构成的的子集 。通过外部参考 ,模型部件可以包含其它的模型选择作为子部件 。模型选择是一种管理项 。
每个类按照如下方式进行描述 :
a) 超类
管理项(源自 MDR) 。
b) 属性
条件 : 串型[1. . 1]
用以指定对模型部件集实施过滤的条件的串 。
c) 参考
由…表达 : 模型记号[1. . 1] ,强制的
表示模型选择所选定的模型部件集的模型记号 。
选择 : 模型部件集[0. . 1] ,强制的
模型选择所选定的模型部件集 。
d) 约束
模型选择由用户社区中的注册机构负责管理和维护 。
模型选择实例包括从其超类 — 管理项继承的名称 ,在注册时应该遵循管理项语言部分的规定 。
4.3 目标包(注册目标的结构)
图 5 表示的是核心模型的目标包 。
图 5 核心模型中的目标包
4.3. 1 模型域轮廓
模型域轮廓是一个具有名称和符合程度说明的元类 。符合程度通过符合声明来表达 。模型域轮廓由相应的模型规约作出描述 ,包含多个模型部件 ,通过遵循 MOF的相关模型进行规范 。模型域轮廓是一种管理项 。
每个类按照如下方式进行描述 :
a) 超类
管理项(源自 MDR) 。
b) 属性
名称 : 串型[1. . 1] ,强制的
用以识别模型域轮廓中每个实例的串 。
符合程度 : 串型[0. . * ] ,可选的
用以识别模型规约中定义的符合程度的串 。
c) 参考
被 . . . 描述 :模型规约[1. . * ] ,可选的
标准或者轮廓的模型规约 。
被 . . . 规定 :遵循 MOF的模型[0. . * ] ,可选的
基于 MOF的模型或者元模型 。
包含 :模型部件[0. . * ] ,可选的
模型域轮廓中聚集的模型部件 。
d) 约束
属性 “名称 ”的取值无须是全局唯一标识符 。
4.3.2 模型规约
模型规约是一种元类 ,它包含一些元数据以描述标准及相关轮廓 。这种描述信息便于人阅读和理解 。模型规约可包含遵循 MOF的模型文档和模型部件文档 。
每个类按照如下方式进行描述 :
a) 超类
无 。
b) 属性
格式 : 串型[1. . 1] ,强制的
表示文档类型(如 ppt、pdf、http等)的串。
来源 :URI[1. . 1] ,强制的
表示材料来源位置的统一资源标识符 。
标准开发组织名称 : 串型[1. . 1] ,可选的
表示标准开发组织的串 。
发布日期 : 日期型[1. . 1] ,可选的
表示发布的 日期 。
版本 :数字型[1. . 1] ,可选的
表示标准或轮廓的版本号 。
标准化阶段 : 串型[1. . 1] ,可选的
表示标准化过程所处的阶段 。
标题 : 串型[1. . 1] ,强制的
表示标准或者轮廓的标题 。
目的 : 串型[1. . 1] ,可选的
表示制定文档的 目的 。
范围 : 串型[1. . 1] ,可选的
表示文档的应用域和范围 。
规范引用 : 串型[0. . * ] ,可选的
表示规范化引用的串 。
术语定义 : 串型[0. . * ] ,可选的
表示描述术语定义的串 。
符合程度 : 串型[0. . * ] ,可选的
表示描述符合程度的串 。
4.3.3 模型构件
模型构件是一种用于表示 UML命名元素集的元类 。模型构件可以包含的命名元素包括模式(模板) 、构造型(标签值) 、代码值和约束等 。
每个类按照如下方式进行描述 :
a) 超类
无 。
b) 参考
拥有 :命名元素[0. . * ] ,可选的
命名元素(源自 MOF) 。
注 : 模型层的标准建模构件可以在元数据注册机制中进行注册以促进互操作 。这些建模构件的共享和管理非常重要 。建模构件包括模式 、构造型 、模板 、标签值 、词汇表和其他类型的元数据 。
4.3.4 模型类元素
在核心模型中 ,模型类元素是一个具有模型类型 、用法类型 、XMI文本 、附件类型和附件等多种属性的元类 。模型类元素将建模单元和类型化模型标识为概念 。模型类元素的定义遵循 UML和 MOF。
每个类按照如下方式进行描述 :
a) 超类
模型构件 。
b) 属性
模型类型 :类型代码[1. . 1] ,可选的
指定模型类元素类型的类型代码(见 4. 2. 2 的表 1) 。
用法类型 :类型代码[1. . 1] ,可选的
指定使用目的的类型代码 。
用法代码集由注册机构负责维护 。
XMI文本 : 串型[0. . 1] ,可选的
指定用以描述 XML模式或者 XML格式的串 。
附件类型 : 串型[0. . 1] ,可选的
指定附件格式(如 ppt、pdf等)的串 。
附件 :URI[0. . 1] ,可选的
指定附属材料位置的统一资源标识符 。
c) 参考
用 UML定义的 :遵循 MOF的模型[0. . 1] ,可选的
遵循 MOF的模型是一个使用 UML语言定义的包 。
d) 约束
模型类元素由一个包组成 ,可以是模型构件的子集 。一个模型单元包含一个包 。
包也可在建模时作为组织构件 。可以使用嵌套 、导入和泛化等方式来管理模型的复杂度 。
模型类元素和相应的代码系统需遵循特定的模型域轮廓 。
4.3.5 遵循 MOF的模型
遵循 MOF的模型是一个元类 ,具有模型层次 、是否与 MOF兼容 、MOF版本等属性 。遵循 MOF的模型可以有一个对应的包中对象 。
每个类按照如下方式进行描述 :
a) 超类
无 。
b) 属性
模型层次 : 串型[1. . 1] ,强制的
指示模型或元模型所在元级层次(如 M2层 、M1层)的串 。
是否遵从 MOF:布尔型[1. . 1] ,强制的
表示元模型是否遵从 MOF的真假值 。
MOF版本号 : 串型[1. . 1] ,可选的
表示 MOF版本号码的串 。
c) 参考
拥有 :包对象[0. . 1] ,强制的
表示元模型的包对象 。建议使用遵从 MOF的模型 。
d) 约束
使用 :模型类元素 [0. . * ] ,可选的
遵循 MOF的模型对应于 MOF元数据体系结构中 M2层或者 M1层的元模型 。
下层模型应该遵循上层模型的抽象句法和相关约束 。
4.3.6 模型部件
在核心模型中 ,模型部件是一个具有模型类元素和模型选择的元类 。模型选择扮演了以插拔方式与外部元素建立关联的角色 。模型部件是一种管理项 。
注 : 模型部件可包含一些模型类元素作为模型元素 。与此同时 ,模型部件可以由模型概念进行独立的概念化 ,这个模型概念由其他的模型类元素负责分类 。
每个类按照如下方式进行描述 :
a) 超类
管理项(源自 MDR) 。
b) 参考
拥有 :模型类元素[1. . * ] ,可选的
模型部件中使用的模型类元素 。
参考 :模型选择[0. . * ] ,可选的
在模型部件中使用 、并参考已注册模型部件集的模型选择 。
c) 约束
模型选择的使用需依据该模型选择所指向的模型部件集 。
4.4 关系包(注册目标的关系)
图 6描述了核心模型的关系包 。
图 6 核心模型的关系包
4.4. 1 模型关联
模型关联是一个元类 ,用以定义模型类元素之间关联 。模型关联为模型类元素上的链接集合提供了一种分类方式 。作为模型关联的实例 ,链接表达了模型类元实例之间的联系 。
每个类按照如下方式进行描述 :
a) 超类
模型类元素 。
b) 参考
端点 :模型关联端点[2. . * ] ,强制的
指定模型类元素间链接端点的角色 。
c) 约束
定义模型关联需要规定两个模型关联端点 。
如果模型关联是有向的 ,应该使用能够指示方向的名称 。
即使没有直接的模型关联 ,从元模型得到的间接关联仍有可能存在 。
4.4.2 模型关联端点
模型关联端点是一个元类 ,用以描述模型关联中的两个端点 。 每个模型关联端点定义了模型概念在模型关联中扮演的角色以及模型概念集上的约束 。
每个类按照如下方式进行描述 :
a) 超类
无 。
b) 属性
名称 : 串型 [1. . 1] ,可选的
用以识别模型关联端点角色的串 。
注释 : 串 [1. . 1] ,可选的
模型关联端点的非形式化描述串 。
c) 参考
无 。
d) 约束
模型关联端点的实例是链接端点 。链接端点定义了在模型关联实例中 ,链接与模型关联端点的模型概念之间的关系 。
4.4.3 模型交换的标准格式
本部分没有指定具体的元数据格式 。但是 ,建议在互操作中使用核心模型的 XMI模式作为元数据交换格式 。如果提供了合适的 XML模式作为轮廓 ,绑定了诸如 ISO/IEC 20944 的其他元数据格式也是允许的 。
5 符合性
5. 1 概要
本部分描述了一个概念元模型 ,而非物理实现 。 因此 ,元模型的实现不需要与规定的完全相符 。但是 ,必须保证元模型和实现之间的双向映射是无二义性的 。
符合的实现需要 :
— 满足 4. 3 的要求 ;
— 确定符合性程度(5. 2) ;
— 确定符合性级别(5. 3) 。
5.2 符合性的程度
MFI核心模型的符合性从 3个方面进行规定 :第一个是值的要求 ;第二个是元数据交换的互操作性 ;第三个是注册内容(如上层模型和下层模型)之间的符合 。
每个类按照如下方式进行描述 :
a) MFI核心模型的符合在表 4 中规定 ;
b) 交换格式的符合在表 4 中规定 ;
c) 注册内容的符合在本部分中没有规定 。
“级别 1”和 “级别 2”实现之间的区别对于同时解决互操作性和扩展性是必要的 。本部分描述了增强互操作性的规范 。扩展是根据用户 、销售商 、协会和行业需要而实施的 。实现符合程度见表 3。
表 3 实现符合性的程度
注 : 使用元模型或基本属性的扩展有可能会造成未定义的行为 。所有严格符合的实现也是符合的实现 。
级别 1 的实现在功能上有局限性 ,但是能够最大程度的实现关于本部分的互操作 。级别 2 的符合实现可以具备更多的功能 ,但其互操作性较差 。
5.3 符合性的级别
实现需要遵循本部分定义的符合性两个级别之 一 。表 4表示符合性级别的信息 。
表 4 符合性级别
5.4 承诺
两种承诺状态之一将被应用于元数据项属性 ,表示请求该属性的条件 。 实施到元数据项的承诺状态是 “已记录 ”或更高状态 。本部分中规定的属性和关系均被声明为强制的或可选的 。
为了达到符合性的 目的 :
a) 强制的属性和关系必须存在 ,并且这些属性和关系应符合本部分的规定 ;
b) 可选的属性和关系不是必须存在的 ,但是如果存在 ,则应符合本部分的规定 。
当且仅当相关元数据项的注册状态是 “已记录 ”或更高状态时 ,上述承诺将被强制实施 。
5.5 实现符合性的声明
本部分的实现应包括一个实现符合性声明 ,说明 :
a) 该实现是否符合或者严格符合(5. 2) ;
b) 符合性级别 1 或级别 2(5. 3) ,或二者皆是 ;
c) 支持或使用哪些扩展 。
5.6 注册的作用和责任
符合需要在注册机构的任务和责任中考虑 ,正如 GB/T 18391. 6—2009:数据元素的注册中说明的 。系统的扩展符合性需要规程的形式化 、各机构的任务和职责达成一致 、软件产品的使用指南和其他系统的转换指南 。这些方面的形式化应和上述条款中符合性需求一致 ,也应与 GB/T 18391. 6—2009等注册机构的作用保持一致 。
附 录 A
(规范性附录)
遵循 MOF的 MDR
A. 1 概述
元数据注册系统元模型在 GB/T 18391中有相应的定义 。数据建模的理论基础是 :所有数据均用以描述自然世界(即论域)中对象的属性 ,数据的基本单元是数据元素 。该元模型使用了许多与数据建模相同的概念数据结构 。
元数据注册系统的关键概念如下所示 :
— 数据 元 素 概 念 : 一 个 可 以 用 数 据 元 素 的 形 式 表 示 的 思 想 , 以 独 立 于 任 何 特 定 表 示 的 方 式 来表达 。
— 概念域 : 数据元素可能取值的内涵构成的集合 。
— 值域 :可允许的取值构成的集合 。
— 数据元素 :数据单元 ,其定义 、标识 、表示和允许值可使用属性集合进行规定 。
GB/T 18391并不期望该注册元模型能够完全符合所有用户的需求 。某些部分 , 比如元模型和模型的注册 ,要用到其他标准定义的一些元数据属性 。 如果没有违背 GB/T 18391 中元模型在结构和内容上潜在的规则 ,那么这种扩充与 GB/T 18391保持了一致 。 可以向 GB/T 18391 的概念模型添加新的类 、关系和属性 。标准的实现者可以在实现中直接使用这些扩充 ,或者他们可以提供设施让注册系统的使用者定义自己的扩展 。
本部分是基于 GB/T 18391开发的 。然而 ,本部分对注册目标进行了扩充以便能够注册复杂的模型和对象 。 于是 ,4个关键的概念被重新定义为本部分所描述的 : 模 型 记 号 、模 型 概 念(包 括 模 型 域 轮廓) 、模型部件集和模型选择 。
至于管理过程和规程 ,本部分遵从 GB/T 18391体系的公共设施 。 目标对象有一个管理项 ,该管理项由遵循 MOF(如图 A. 1 和图 A. 2)的元模型进行规约 。在本部分中 ,公共设施按照下列方式应用到所有管理项 :
— 管理项在注册系统中只能够被标识一次 ,并且作为单独的项进行管理 。
— 管理项至少在一个语境中进行命名和定义 ,允许在多个语境中进行命名和定义 。在每个语境中 ,名称和定义可以用一种或多种语言来规定 。
图 A. 1 MDR包(管理和标识)
图 A.2 MDR 注册包(语境、命名和定义)
A.2 管理项的命名规则
数据标识符可以被指派给已注册的管理项 。在注册机构中 ,每个管理项应该有一个唯一的数据标识符 。注册机构标识符 , 数 据 标 识 符 和 版 本 标 识 符 共 同 组 成 了 管 理 项 的 唯 一 标 识 符 。 更 详 细 信 息 见GB/T 18391. 6—2009。
注册机构标识符(RAI) 、数据标识符(DI)和版本标识符(VI)组成了国际注册数据标识符 。 每个管理项都需要有一个国际注册数据标识符 。
数据标识符需要由注册机构指定 ;数据标识符在一个注册机构的辖域内应该是唯一的 。 由于每个注册机构有可能会确定它自己的数据标识符分配模式 , 因此无法保证数据标识符本身能够唯一的识别
管理项 。为了识别管理项 ,数据标识符和注册机构标识符都是必需的 。管理项的每个名称都需要在特定的语境中来规定 。表 A. 1 中提供了核心模型中管理项的命名传统 。
表 A. 1 国际注册数据标识符的命名传统
A.3 命名的例子
命名的例子如下 :
a) 名称(记号/概念/域/注册机构标识符/版本)
“国家/国家和地区/全球疆界/日本国/1. 0 版 ”
b) 模型概念(概念/域/注册机构标识符/版本)
“国家和地区/全球疆界/联合国/2. 0 版 ”
c) 模型部件集(部件集/概念/注册机构标识符/版本)
“ISO/IECJTC1参加国成员/国家和地区/日本国/1. 0 版 ”
d) 模型选择(选择/记号/部件集/注册机构标识符/版本)
“情报理学会/国家/ISO/IECJTC1参加国成员/日本国/2. 0 版 ”
e) 模型域轮廓(域/注册机构标识符/版本)
“全球疆界/联合国/3. 0 版 ”
f) 模型部件(部件/注册机构标识符/版本)
“加拿大/联合国/2. 0 版 ”
“日本/联合国/2. 0 版 ”
“美国/联合国/2. 0 版 ”
“韩国/联合国/2. 0 版 ”
“英国/联合国/2. 0 版 ”
“澳大利亚/联合国/2. 0 版 ”
“中国/联合国/2. 0 版 ”
附 录 B
