DLIS-RP66-PART-1

Part 1: Model and Methodology
第1部分：模型与方法

Edition 1
1 - Scope
1 -范围
This part specifies a methodology for managing (generating and maintaining) a schema specification for data to be recorded under the RP 66, V2 format.
本部分规定了一种方法来管理（生成和维护）架构规范，数据记录下的反相66 ， v2的格式。

This document is intended to:
本文档的目的是：

Facilitate the development of exchange standards based on the RP 66, V2 format.
Facilitate the development of schema-neutral software products and services, by promoting uniformity between RP 66, V2-based exchange standards.
Promote compatibility between editions of a schema.
促进发展交换标准的基础上反相66 ， v2的格式。
促进发展模式中立的软件产品和服务，促进统一的反相66 ， 2版为基础的交换标准。
促进之间的兼容性版本架构。

2 - Definitions
2-定义

3 - Concepts
3 -概念

A logical model is the conceptual organization of a domain of knowledge: What classes of things are of interest, and what are their characteristics and the relationships between them which are of interest? A logical model is a framework for common understanding of the nature of classes of things, but is not sufficient for communication about individual members of the classes.
一个合乎逻辑的概念模型是组织域的知识：什么类型的事情感兴趣，而且他们有什么特点和它们之间的关系有兴趣？一个合乎逻辑的模式是一个框架的共同理解的性质，类别的事情，但是没有足够的沟通，个别成员的课程。

An implementation model, also called a schema, is a formalized description of the encoding of information defined by the logical model, typically in terms of a representational model. How are general representational constructs used to encapsulate information about the elements defined in the logical model? A schema must be sufficiently dynamic to meet new requirements, and yet must be sufficiently stable that change requirements are not unnecessarily imposed on the systems which use it.
一个执行模式，也称为架构，是一个形式化描述的编码信息所界定的逻辑模型，通常是在一个代表性的模式。大会代表是如何构建用于封装信息内容界定的逻辑模型？架构必须有足够的动力以满足新的要求，但必须有足够的稳定，这种改变要求是不必要对系统的使用它。

A representational (or data) model is a description of the specification and representation paradigm to be used. What are the fundamental representational constructs and their organization? How is the schema specified? How is data organized, encoded, stored, and decoded?
一个代表处（或数据）模型是一种描述规范和代表性的范例使用。什么是代表的基本构造和他们的组织？如何架构指定？如何组织数据，编码，储存和解码？

The purpose of a schema specification for an exchange format is to enable the exchange of information in some domain of knowledge.
的目的架构规格交换格式，使信息交流在某些领域的知识。

4 - Audience
This document is intended for:
Original authors and maintainers of schema specifications.
Readers of schema specifications.
Developers of schema-neutral RP 66, V2 software layers and systems.
It is assumed that the reader has a basic understanding of logical models, and has a particular logical model in mind. No particular modeling formalism is assumed; indeed, the schema specification may itself be the only formal expression of the logical model.
RP 66, V2 is a general-purpose data exchange mechanism which is not bound to a specific logical model. The purpose for using a standard methodology for schema specification is to enable the implementation of data exchange using model-driven software layers.
5 - Schema Categories
Schemas may be categorized as managed, derived, and local.
A managed schema exists from the definition of its initial edition, through subsequent editions, until all data recorded under it are no longer of interest (i. e., indefinitely). During this life cycle each edition of a schema is expected to meet certain requirements for compatibility or continuity with previous editions. As the logical model and usage requirements change new editions of the schema are developed, subject to these constraints.
A derived schema is one which is systematically derived or inferred from a formalized logical model according to a deterministic methodology. In this case a human-readable schema specification might not be produced. Furthermore, the schema edition reflects the version of the derivation methodology and the versioning policy under which it is governed. The logical model may be governed under a different versioning policy. Organizations that define derivation methodologies should provide mechanisms to record and identify the author, name, and edition of the logical model from which the schema is derived.
A local schema is one that is neither managed nor derived but is used for local exchange or storage of data using the data model.
This document is normatively applicable to managed schemas only.
6 - Schema Administration
An organization must have been issued an organization code to publish a managed schema or a schema derivation methodology. Code 999 is reserved for local schema. An organization code is assigned on request, by POSC, which also maintains the most current list of organization codes. Its address is listed at the end of the Foreword.
The holder of an organization code may publish (editions of) a schema or a schema derivation methodology under that code. An organization that wishes to manage multiple schemas may obtain multiple organization codes. No other constraints apply among schemas, but certain constraints apply between editions of a managed schema. If a schema element is defined under two editions, then it has the same meaning and use in both editions. Elements may be dropped from one edition to the next and new elements may be added, but elements may not be redefined.
Alternatively, an organization may manage multiple schemas by defining a derivation methodology under an organization code for mapping an appropriate class of logical models into derived schemas.
In general, it is expected that an organization that publishes a schema or a schema derivation methodology will also publish the specific versioning policy governing compatibility and constraints between editions. Derived schemas editions are determined indirectly by reflecting the logical model edition along with the name and edition of the derivation methodology applied to the logical model.
7 - Data Model
RP 66, V2 schema specifications are defined in terms of object types, attributes, and the rules about them. These data model elements are described in detail in Part 2, "Logical Format."
The specification of an object type includes its name, its semantics, its attributes, and whether its instances have controlled names. No relation shall be assumed between object types in different schemas having the same type names.
The specification of an attribute includes its label, its semantics, and any restrictions on its count, representation code, units, or value. Unless explicitly stated, no relation shall be assumed between attributes in different object types having the same labels.
An instance of an object type is constrained by its object type specification. An object may have all, some, or none of the attributes defined for it, and shall not have attributes not defined for it or duplicates of the attributes defined for it.
An instance of an attribute is constrained by its specification in the object type of the object in which it appears. An attribute has exactly one occurrence of each type of characteristic: label, count, representation code, units, and value. The label identifies the attribute in terms of its definition in the object type. The value is composed of zero or more elements, or occurrences of the data representation identified by its representation code. It has a single count, which is the number of elements in its value. It has a single units value, which applies to each element of the value.
The logical file is the logical unit of data exchange, and is a collection of objects and other data described by its objects. The object is the unit of data which may be uniquely referenced within a logical file. An object is a collection of the attributes defined for its type, with assigned values. A logical file may contain objects from any number of schemas, and objects may refer to objects in different schemas in the same logical file.
8 - Schema Specification
8.1 - Preliminary Part
The preliminary part of a schema specification may include the following:
title page.
table of contents.
foreword.
introduction.
8.2 - Normative Part
The normative part of a schema specification may include the following:
context.
title.
scope.
normative references.
authority.
sanctioning organization.
document preparation, revision, and review committees.
proprietary considerations.
revision and versioning policies.
edition.
edition level.
summary of this and recent editions.
document status (draft or final).
definitions.
define terminology introduced.
normative references to other defining documents.
model.
definition, presentation, or description of the logical model, or reference to equivalent documentation.
schema.
definition of object types and their attributes.
constraints on objects and attributes.
relationships to corresponding elements of the logical model.
dictionary.
tables of reference values, to which attributes they apply, and their meanings.
units.
specification of unit model(s) and unit dictionary(ies) used in the schema (if not API-SI units).
identification of units model in attribute restriction specifications.
normative appendices.
8.3 - Supplementary Part
The supplementary part of a schema specification may include the following:
informative appendices.
footnotes.
8.4 - Object Type Specification
An object type is specified by providing a unique type identifier, dictionary constraints on the identifier subfield of the name, a set of attributes, and the intended use of the object. An object type specification typically has the following parts:
type name.
context - a description of the semantics of the object type or reference to a logical model.
attribute specifications.
8.5 - Attribute Specification
The characteristics of an attribute are its label, count, representation code, units, and value. The formal specification of an attribute includes its label, and may include constraints on the remaining characteristics.
The formal specification of the set of attributes defined for an object type is presented in a single table, followed immediately by a set of numbered notes. The columns of the attribute specification table are:
Attribute Label: a valid IDENT value, unique in the object type.
Restrictions: a set of restrictions on the count, representation code, units, or value characteristics of an attribute. Restriction specifications are of the form `q1=r1, q2=r2, ... qn=rn', where `qn' is the characteristic identifier and `rn' is a restriction specification. The characteristic identifier is lower case. When no restrictions apply, the identifier is omitted. Restriction specifications are stated in the order `c=..., r=..., u=..., v=...'.
A count restriction is specified as `c={[min1:max1], [min2:max2], ...,[minn:maxn]}', where mink and maxk represent bounds, or `?' if the interval lacks an upper or lower bound. If a single boundary set is specified, the curly braces (`{`, `}') are omitted. If the minimum and the maximum are equal for any boundary range, the square brackets (`[`, `]'), colon (`:'), and second range limit are omitted.
The representation code retriction is specified as `r=XXX | YYY | ZZZ', where XXX, YYY, and ZZZ are alternative representation codes. If a single representation code is specified, the vertical bar `|' is omitted. For each representation code, an alternative representation in the same representation code class may be used, but the value shall be representable in one of the specified representation codes.
The units restriction is specified as `u=um:uexp', where um identifies the units model and its dictionary, and uexp is a units expression in that units model. If the `um:' prefix is omitted, then a default unit model shall apply if declared in the general context part of the schema specification. The specification `u=' indicates the attribute value is unitless. When the unit model is API-SI, then restriction to a unit represents a typical or preferred use, although another unit having the same canonical form may be used. A unit having a different canonical form shall not be used.
The value restriction is specified as `v=ref', where ref may refer to the note or to a table of reference values for the attribute. Reference values are dictionary-controlled values belonging to an enumerated set. A schema may declare a value to consist of reference values and defer actual definition of the reference values to other schemas that may use the attribute's object type. A schema may provide an actual table of reference values or a normative reference to them.
Notes: Numbered references to notes that immediately follow the table. Notes are free-format descriptions of semantics and other rules about the attribute and its relation to other attributes.
9 - Notation: How to Refer to an Attribute
The notation TYPE:LABEL is used to refer to an attribute in a schema, where TYPE is the object type and LABEL is the attribute label. TYPE may be omitted if understood from context. If the schema is not clear from the context of the referral, then the additional notation n/TYPE:ATTRIBUTE is used, where n is the schema code of the object type.
10 - Dictionary Specification
10.1 - Preliminary Part
The preliminary part of the dictionary may include the following:
title page.
table of contents.
foreword.
introduction.
10.2 - Normative Part
The normative part of the dictionary may include the following:
context.
title.
scope.
normative references.
schema: a reference to the schema (schema code, schema name, schema edition) and dictionary specification within the schema for which the dictionary is applicable.
authority.
sanctioning organization.
document preparation/revision/review committees.
proprietary considerations.
revision and versioning policies.
edition.
edition level.
summary of this and recent editions.
document status (draft or final).
definitions.
terminology.
normative references to other defining documents.
description of the reference value tables.
reference value tables.
title which identifies the attribute restricted to the reference values.
reference value column.
description column.
other columns as required by the schema.
10.3 - Supplementary Part
The supplementary part of the dictionary may include the following:
informative appendices.
footnotes.

 

 

4 -观众
这个文件的目的是为：

原始作者和维护者的架构规范。
读者架构规格。
开发的架构中立反相66 ， v2的软件层和系统。
假定读者有一个基本的了解逻辑模型，并具有特殊逻辑模型铭记。没有特别的造型形式主义假定;事实上，架构规范本身可能是唯一的正式表达的逻辑模型。

反相66 ， v2的是一个一般用途的数据交换机制，这是不是绑定到具体的逻辑模型。的目的，使用标准方法的模式规范是使执行数据交换使用模型驱动的软件层。

5 -模式分类
模式都可被归类为管理，导出和地方。

有管理的模式存在的定义的初始版，通过以后的版本，直到所有的数据记录在它已不再感兴趣（即无限期） 。在这个生命周期的每一个版本的架构，可望满足某些要求的相容性或连续性与以往的版本。逻辑模型和使用要求的新版本中变化的架构的开发，但这些限制。

一种衍生模式是指系统所衍生或推断正式逻辑模型根据确定性的方法。在此情况下，人类可读的架构规格可能不产生。此外，该架构版反映了版本的推导方法和版本控制的政策下，它的管辖。逻辑模型可能要根据不同版本的政策。组织推导方法确定应提供机制，以记录，并确定作者，名称，版本的逻辑模型从架构的计算公式。

当地的架构是一个既不是管理，也没有产生，但用于本地交换或存储数据使用的数据模型。

这份文件是规范管理的模式适用于只。

6 -架构管理
一个组织必须已经发出了组织机构代码出版管理模式或架构推导方法。码999是保留给当地架构。一个组织机构代码是指定的要求， POSC ，这也保持最新的清单，组织代码。其地址是结束时的前言。

持有人的组织机构代码可公布（版）架构或架构下推导的方法代码。一个组织要管理多个架构可获取多种组织代码。没有其他限制，适用于除架构，但某些限制之间适用版本的，有管理的架构。如果架构要素的定义是根据两个版本，那么它具有相同的含义和使用的两种版本。内容可能是从一个版本的下和新的内容可能会增加，但内容不得重新界定。

此外，一个组织可以管理多个架构的推导方法，确定了下一个组织机构代码的映射一个适当的类的逻辑模型到衍生模式。

一般情况下，预计该组织出版模式或架构推导的方法也将出版管理政策的具体版本的相容性和制约因素之间的版本。衍生架构版本决心间接反映了逻辑模型版连同名称和版本的推导方法的逻辑模型。

7 -数据模型
反相66 ， v2的架构规范中定义的对象类型而言，属性，和他们的规则。这些数据模型的内容中详细说明第2部分， “逻辑格式。 ”

该规范的对象类型，包括其名称，它的语义，其属性和它的情况下，是否有控制的名字。没有关系，应承担的对象类型之间的不同模式具有相同类型的名字。

该规范的属性，包括它的标签，其语义，以及任何限制其数量，代表性代码，单位，或价值。除非另有明确规定，没有关系，应承担的属性类型不同对象具有相同的标签。

一个实例的对象类型的限制，其对象类型规格。一个对象可能有，一些，或没有为它定义的属性，并不得有属性没有定义的，或重复的定义的属性的。

一个实例的属性的限制，其规范的对象类型的对象，其中会出现。属性已整整发生的每种类型的特征：标签，数量，代表性代码，单位，和价值。标签标识属性在其定义的对象类型。该值是由零个或多个元素，或发生代表性的数据确定其代表性的代码。它有一个单一的数量，这是一些内容的价值。它有一个单一的单位价值，适用于各组成部分的价值。

逻辑文件是逻辑单元的数据交换，是一个收集的对象和其他数据所描述的其宗旨。对象是该单位的数据可能是唯一合乎逻辑的引用文件。一个对象的集合属性定义的类型，与指定值。一个合乎逻辑的文件可能包含对象从任何数量的模式，和对象可参照物体在不同的模式在同一逻辑文件。

8 -架构规范
8.1 -初步部分
初步架构的一个组成部分规格可包括以下内容：

书名页。
目录。
前言。
导言。
8.2 -规范部分
规范性架构的一个组成部分规格可包括以下内容：

背景。
标题。
范围。
规范性引用。
权威。
制裁的组织。
文件的编写，修订和审查委员会。
专有的考虑。
修订和版本控制的政策。
版。
版的水平。
总结这和最新版本。
文件状态（草案或最后） 。
定义。
定义用语。
规范提到其他定义文件。
模型。
的定义，介绍或说明的逻辑模型，或参照同等文件。
架构。
定义对象类型及其属性。
限制对象和属性。
关系到相应的内容的逻辑模型。
字典。
表的参考价值，因为它们适用的属性，它们的含义。
单位。
规格单位模型（ s ）和单位字典（处）中使用的模式（如果不是的API - SI单位） 。
鉴定单位模型属性限制规范。
规范性附录。
8.3 -补充部分
补充部分的架构规格可包括以下内容：

内容丰富的附录。
脚注。
8.4 -对象型号规格
一个对象指定类型，提供了一个独特的类型标识符，字典上的限制标识符子字段的名称，一组属性，并打算使用的对象。一个对象类型的规格一般有以下部分：

类型名称。
背景-描述了语义的对象类型或交逻辑模型。
属性规格。
8.5 -属性规格
特性的属性是它的标签，数量，代表性代码，单位，和价值。正式规范的属性，包括它的标签，并且还可能包括限制剩余的特点。

正式规范的一套定义的属性的对象类型是在一个单一的表，然后立即一套编号说明。列属性规格表如下：

属性标签：一个有效的识别价值，独特的对象类型。
限制：一套限制数量，代表性代码，单位，或价值特征的属性。规格限制的形式` 1 =受体1 ，第2季= R2的， ...每晚=护士' ，其中`每晚'是特性标识符和`护士'是有限制的规范。标识符的特点是小写。如果没有限制，标识符省略。规格限制命令中所述` ç =..., r =..., ü =..., v =...'.
计数限制规定和` C = （ [民： max1 ] ， [民： max2 ] ， ...,[闵： maxn ] ） ' ，其中水貂和maxk代表跨越，或` ？ '如果间隔缺少一个上限或下限。如果单一边界设置指定的大括号(`{`, ` ） ' ）的省略。如果最低和最高都是平等的任何边界范围内，方括号(`[`, `]'),和第二大(`:'),范围限制是省略。
任职代码retriction被指定为` r =三十| YYY |译成zzz ' ，其中xxx ， YYY ，并译成zzz是替代代表守则。如果单一的代表性代码指定，竖线` | '省略。对于每一个代表性的代码，另一种代表在同一类席位代码可以使用，但价值应representable在一个指定的代表性法典。
这些单位的限制被指定为` ü =嗯： uexp ' ，在这个确定的单位模型及其字典，和uexp是一个单位的表达单位的模式。如果`嗯： '前缀是省略，那么默认的单元模型应适用于被宣布为在一般情况部分架构规范。规格` ü = '显示属性值是unitless 。当空气污染指数单元模型是市，然后限制，一个单位是一个典型的或倾向于使用，但另一股具有相同的规范形式可能会被使用。一个单位有不同的规范形式，不得使用。
限制的价值被指定为` ν =参' ，其中编号可参考的说明或一个表的参考价值属性。参照值的字典控制值属于枚举集。架构，可宣布价值包括推迟参考价值和实际定义的参考值，以其他模式可以使用该属性的对象类型。架构可以提供一个实际的表的参考价值或规范提到它们。
注：编号提到指出，紧接就座。注释是免费的格式描述语义和其他规则的属性及其与其他属性。
9 -符号：如何提及属性
符号型：标签是用来指一个属性的架构，其中一种是对象类型和标签属性的标签。型可省略，如果从上下文理解。如果模式没有明确的背景下转诊，那么额外的符号ñ /类型：属性是使用，其中n是架构代码的对象类型。

10 -字典规范
1月10日-初步部分
初步一部分字典可包括以下内容：

书名页。
目录。
前言。
导言。
10.2 -规范部分
规范词典的一部分，可包括以下内容：

背景。
标题。
范围。
规范性引用。
架构：参考架构（架构代码，架构名称，架构版）和字典规范架构内的字典是适用的。
权威。
制裁的组织。
文件编写/修订/审查委员会。
专有的考虑。
修订和版本控制的政策。
版。
版的水平。
总结这和最新版本。
文件状态（草案或最后） 。
定义。
术语。
规范提到其他定义文件。
说明参考价值表。
参考值表。
标题识别属性限制的参考价值。
参考值列。
说明栏。
其他栏目所要求的模式。
3月10日-补充部分
补充部分字典可包括以下内容：

内容丰富的附录。
脚注。