metadata_specf
metadatareportconfig参数详解
一、metadatareportconfig参数是什么？metadatareportconfig参数是一种用于配置数据报告的参数，它可以用于指定报告的元数据内容、格式和展示方式，从而实现对报告的灵活定制和控制。
二、metadatareportconfig参数的作用是什么？1.指定报告的元数据内容metadatareportconfig参数可以指定报告中显示的元数据内容，比如报告中需要展示哪些数据项、数据字段的格式、数据类型等。
通过配置这些参数，可以使报告的内容更加丰富和有针对性。
2.指定报告的格式metadatareportconfig参数可以指定报告的展示格式，比如报告的布局、字体、颜色等，从而使报告更加美观和易读。
3.控制报告的展示方式metadatareportconfig参数还可以控制报告的展示方式，比如报告的展示方式是上线查看、下载或者打印，以及相关的权限和安全控制等。
三、metadatareportconfig参数的常用设置有哪些？1.报告内容设置可以通过metadatareportconfig参数指定要展示的数据项、字段、元数据类型等内容，比如指定报告中需要包含哪些数据表、字段类型为文本、日期等。
2.报告格式设置可以通过metadatareportconfig参数指定报告的展示格式，比如通过设置报告的风格、字体、颜色等来实现报告的美化和定制。
3.报告展示方式设置可以通过metadatareportconfig参数指定报告的展示方式，比如指定报告是上线查看、下载或者打印，以及相关的权限和安全控制等。
四、如何使用metadatareportconfig参数进行配置？1.了解报告需求首先需要了解报告的需求，比如需要展示哪些数据、展示的方式、格式等，然后根据需求进行相应的配置。
2.配置metadatareportconfig参数在配置报告的过程中，需要根据报告的需求进行metadatareportconfig参数的配置，比如设置报告的元数据内容、格式和展示方式等。
k8s学习笔记之五：Pod资源清单spec字段常用字段及含义
k8s学习笔记之五：Pod资源清单spec字段常⽤字段及含义第⼀章、前⾔在上⼀篇博客中，我们⼤致简述了⼀般情况下资源清单的格式，以及如何获得清单配置的命令帮助，下⾯我们再讲解下清单中spec字段中⽐较常见的字段及其含义第⼆章、常⽤字段讲解spec.containers <[]object>spec.containers <[]object> <string> #pod的名称，必须字段，名称唯⼀且对象创建后不可以被修改spec.containers.image <string> #镜像仓库的路径/镜像的名称：镜像的标签spec.containers.image.imagePullPolicy <string> #镜像的下载策略。
有三种：Always(总是去仓库下载) ,Never(从不去仓库下载) , IfNotPresent(如果本地没有就去仓库下载) 默认是"IfNotPresent"但是，如果镜像的标签是latest，则总会是"Always，并且对象⼀旦被创建，这个字段不允许被改变spec.containers.ports: #容器公开的端⼝列表。
在这⾥公开端⼝可以为系统提供关于容器使⽤的⽹络连接的额外信息，但主要是提供信息。
在这⾥不指定端⼝不会阻⽌该端⼝被公开。
任何 spec.containers.ports.containerPort <integer> -required- #pod暴露的端⼝，此端⼝仅是额外的信息，对端⼝是否被暴露没有影响spec.containers.ports.hostPort <integer> #主机上公开的端⼝spec.containers.ports.protocol <string> #端⼝的协议spec.containers.ports.hostIP <string> #指定要绑定的主机mand <[]string> #运⾏的程序，类似于docker中的entrypion t,并且这⾥的命令不会运⾏在shell中，如果没有这个字段docker镜像会运⾏⾃⼰entrypiont中的指令spec.containers.args <[]string> #向docker镜像中传递参数如果定义了这个字段，docker镜像中cmd命令不会被执⾏，如果引⽤变量使⽤$(VAR_NAME)格式引⽤，如果想使⽤命令引⽤的的⽅式，需要#关于args和command的官⽅⽂档链接：https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/ pod.spec.containers.volumeMounts pod.spec.containers.volumeMounts.mountPath #可以被容器挂载的存储卷的路径，路径不能包含':'符号 pod.spec.containers.volumeMounts.subPath #可以被容器挂载的存储卷的路径，并且不会覆盖挂载点中的⽂件 pod.spec.containers.volumeMounts.readOnly #是否只读，默认为falsepod.spec.containers.resources spec.containers.resources.limits #资源限制 spec.containers.resources.limits.cpu ： CPU 上限，可以短暂超过，容器也不会被停⽌ spec.containers.resources.limits.memory ：内存上限，不可以超过；如果超过，容器可能会被终⽌或调度到其他资源充⾜的机器上 spec.containers.resources.requests #资源需求 spec.containers.resources.requests.cpu ： CPU 请求，也是调度 CPU 资源的依据，可以超过 spec.containers.resources.requests.memory ：内存请求，也是调度内存资源的依据，可以超过；但如果超过，容器可能会在 Node 内存不⾜时清理spec.nodeSelector <map[string]string>pod.spec.nodeSelector: #指定对象的调度节点,节点必须存在pod.spec.restartPolicy <string>pod.spec.restartPolicy：#容器的重启策略。
openmetadata 源码编译
本文将介绍如何使用openmetadata源码进行编译的详细步骤，帮助读者深入了解openmetadata的开发过程，同时也方便读者在自己的环境中进行编译和部署。
一、准备工作1.1 确认开发环境在进行openmetadata源码编译前，需要确认自己的开发环境是否满足要求。
openmetadata的冠方文档中会给出明确的开发环境要求，通常包括操作系统版本、编译器版本、依赖库版本等。
读者需要仔细阅读冠方文档，确保自己的开发环境符合要求。
1.2 获取源码在准备工作阶段，读者需要获取openmetadata的源码。
通常情况下，可以通过git工具从开源仓库中获取最新的源码。
获取源码后，建议创建一个新的开发分支，以便后续的开发和调试。
1.3 安装必要的工具和依赖库在编译openmetadata源码之前，需要安装一些必要的工具和依赖库。
这些工具和依赖库可以包括编译器、构建工具、第三方库等。
读者需要根据冠方文档的指引，逐一安装这些必要的工具和依赖库。
二、源码编译2.1 配置编译选项在进行源码编译之前，读者需要对编译选项进行配置。
这些编译选项可以包括目标评台、调试信息、优化级别等。
不同的编译选项会对最终的可执行文件产生影响，因此读者需要根据实际需求进行合理的配置。
2.2 执行编译命令配置完成编译选项后，读者可以执行编译命令，开始编译openmetadata源码。
编译过程中会生成各种中间文件和可执行文件，读者需要耐心等待编译过程完成。
2.3 检查编译结果编译完成后，读者需要检查编译结果。
通常情况下，会生成可执行文件、静态库、动态库等。
读者需要对这些编译结果进行检查，确保编译过程没有出现错误。
三、部署和测试3.1 配置部署环境在编译完成后，读者需要进行部署和测试。
部署环境通常包括目标评台的操作系统、依赖库的安装等。
读者需要根据实际情况进行合理的配置，确保部署环境能够正常运行编译生成的可执行文件。
3.2 执行部署命令配置完成部署环境后，读者可以执行部署命令，将编译生成的可执行文件部署到目标评台上。
metadata crc error detected
metadata crc error detected"Metadata CRC Error Detected" - 介绍和解决方法"Metadata CRC Error Detected" 是一个常见的错误消息，经常出现在计算机或存储设备上。
该错误可能会导致您的文件或数据损坏或丢失。
无论您是在进行数据存储还是传输，了解如何解决该错误可能会帮助您保护您的数据。
在下面的文章中，我们将逐步介绍什么是“Metadata CRC Error Detected”，以及如何解决它。
1. 什么是“Metadata CRC Error Detected”？CRC 意味着循环冗余校验码（Cyclic Redundancy Check），是一种用于检测文件传输中错误的错误检查技术。
数据的循环冗余校验码是在传输过程中生成的，以确保数据在传输过程中没有被损坏或修改。
当数据传输中的校验和损坏或错误时，就会出现“Metadata CRC Error Detected”错误消息。
2. 可能会导致“Metadata CRC Error Detected”错误的原因这个错误可能有几个原因，其中包括：- 坏的扇区或硬盘损坏- 数据损坏或传输错误- 病毒或恶意软件感染- 系统故障或错误- 存储设备或工具老化或损坏3. 如何解决“Metadata CRC Error Detected”错误？解决这个错误需要特定的方法，取决于问题的根本原因。
下面是几种常见的方法：1) 检查存储设备或工具首先，您需要检查存储设备或工具的硬件是否存在问题。
检查一下是否有损坏或磁盘扇区损坏。
您还可以尝试使用其他存储设备或工具来查看数据是否具有相同的问题。
2) 检查文件传输在文件传输期间可能会出现数据损坏或传输错误。
尝试使用其他传输方法或软件。
可以使用互联网上的一些专业的传输软件等等。
3) 扫描您的系统以查找病毒或恶意软件病毒或恶意软件可能会损坏您的数据，这可能会导致出现“Metadata CRC Error Detected”错误。
K8S内部服务调用域名解析超时
K8S内部服务调⽤域名解析超时前⾔近期线上 k8s 时不时就会出现⼀些内部服务间的调⽤超时问题，通过⽇志可以得知超时的原因都是出现在域名解析上，并且都是 k8s 内部的域名解析超时，于是直接先将内部域名替换成 k8s service 的 IP，观察⼀段时间发现没有超时的情况发⽣了，但是由于使⽤ service IP 不是长久之计，所以还要去找解决办法。
复现⼀开始运维同事在调⽤⽅ pod 中使⽤ab⼯具对⽬标服务进⾏了多次压测，并没有发现有超时的请求，我介⼊之后分析ab这类 http 压测⼯具应该都会有 dns 缓存，⽽我们主要是要测试 dns 服务的性能，于是直接动⼿撸了⼀个压测⼯具只做域名解析，代码如下：package mainimport ("context""flag""fmt""net""sync/atomic""time")var host stringvar connections intvar duration int64var limit int64var timeoutCount int64func main() {// os.Args = append(os.Args, "-host", "", "-c", "200", "-d", "30", "-l", "5000")flag.StringVar(&host, "host", "", "Resolve host")flag.IntVar(&connections, "c", 100, "Connections")flag.Int64Var(&duration, "d", 0, "Duration(s)")flag.Int64Var(&limit, "l", 0, "Limit(ms)")flag.Parse()var count int64 = 0var errCount int64 = 0pool := make(chan interface{}, connections)exit := make(chan bool)var (min int64 = 0max int64 = 0sum int64 = 0)go func() {time.Sleep(time.Second * time.Duration(duration))exit <- true}()endD:for {select {case pool <- nil:go func() {defer func() {<-pool}()resolver := &net.Resolver{}now := time.Now()_, err := resolver.LookupIPAddr(context.Background(), host)use := time.Since(now).Nanoseconds() / int64(lisecond)if min == 0 || use < min {min = use}if use > max {max = use}sum += useif limit > 0 && use >= limit {timeoutCount++}atomic.AddInt64(&count, 1)if err != nil {fmt.Println(err.Error())atomic.AddInt64(&errCount, 1)}}()case <-exit:break endD}}fmt.Printf("request count：%d\nerror count：%d\n", count, errCount)fmt.Printf("request time：min(%dms) max(%dms) avg(%dms) timeout(%dn)\n", min, max, sum/count, timeoutCount)}编译好⼆进制程序直接丢到对应的 pod 容器中进⾏压测：# 200个并发,持续30秒./dns -host {service}.{namespace} -c 200 -d 30这次可以发现最⼤耗时有5s多，多次测试结果都是类似：⽽我们内部服务间 HTTP 调⽤的超时⼀般都是设置在3s左右，以此推断出与线上的超时情况应该是同⼀种情况，在并发⾼的情况下会出现部分域名解析超时⽽导致 HTTP 请求失败。
Kubernetes全栈架构师（二进制高可用安装k8s集群扩展篇）--学习笔记
Kubernetes全栈架构师（⼆进制⾼可⽤安装k8s集群扩展篇）--学习笔记⽬录⼆进制Metrics&Dashboard安装⼆进制⾼可⽤集群可⽤性验证⽣产环境k8s集群关键性配置Bootstrapping: Kubelet启动过程Bootstrapping: CSR申请和证书颁发原理Bootstrapping: 证书⾃动续期原理⼆进制Metrics&Dashboard安装安装CoreDNS安装Metrics Server安装dashboard安装CoreDNS安装对应版本（推荐）cd /root/k8s-ha-install/如果更改了k8s service的⽹段需要将coredns的serviceIP改成k8s service⽹段的第⼗个IPsed -i "s#10.96.0.10#10.96.0.10#g" CoreDNS/coredns.yaml安装corednskubectl create -f CoreDNS/coredns.yaml安装最新版CoreDNS（不推荐）git clone https:///coredns/deployment.gitcd deployment/kubernetes# ./deploy.sh -s -i 10.96.0.10 | kubectl apply -f -serviceaccount/coredns createdclusterrole.rbac.authorization.k8s.io/system:coredns createdclusterrolebinding.rbac.authorization.k8s.io/system:coredns createdconfigmap/coredns createddeployment.apps/coredns createdservice/kube-dns created查看状态kubectl get po -n kube-system -l k8s-app=kube-dns状态NAME READY STATUS RESTARTS AGEcoredns-fb4874468-nr5nx 1/1 Running 0 49s强制删除⼀直处于Terminating的pod[root@k8s-master01 ~]# kubectl get po -n kube-system -l k8s-app=kube-dnsNAME READY STATUS RESTARTS AGEcoredns-fb4874468-fgs2h 1/1 Terminating 0 6d20h[root@k8s-master01 ~]# kubectl delete pods coredns-fb4874468-fgs2h --grace-period=0 --force -n kube-systemwarning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.pod "coredns-fb4874468-fgs2h" force deleted[root@k8s-master01 ~]# kubectl get po -n kube-system -l k8s-app=kube-dnsNo resources found in kube-system namespace.安装Metrics Server在新版的Kubernetes中系统资源的采集均使⽤Metrics-server，可以通过Metrics采集节点和Pod的内存、磁盘、CPU和⽹络的使⽤率。
ovs metadata 详解(一)
ovs metadata 详解(一)OVS Metadata 详解什么是 OVS MetadataOVS（Open vSwitch）是一种基于软件定义网络（Software-Defined Networking）的虚拟交换机，它能够在数据中心网络中提供灵活的网络管理和控制功能。
在 OVS 中，Metadata 是指附加在数据包上的元数据。
Metadata 的作用Metadata 可以用来传递和存储一些与数据包相关的额外信息，以便在网络交换机上进行处理和传递。
信息可以包括例如虚拟机的标识、服务质量要求或者其他自定义的控制信息。
Metadata 的嵌入方式在 OVS 中，Metadata 可以嵌入在数据包的头部，具体有两种方式：1.Direct Flow Rule（直接流规则）： Metadata 以单独的字段存在于 OVS Flow 相关的数据包头部，例如 OpenFlow类型的协议中的 Table-Miss Flow 表项。
2.Indirect Flow Rule（间接流规则）： Metadata 通过匹配特定字段的方式嵌入在数据包头部，例如 OpenFlow 协议中的 Match 表项。
Metadata 的使用场景Metadata 的使用可以根据具体需求进行定制，常见的使用场景包括：•虚拟机标识： Metadata 可以用来标识、区分不同的虚拟机，以便实现虚拟机间通信和网络隔离。
•服务质量要求： Metadata 可以用来定义和传递特定数据包的服务质量要求，例如带宽限制、延迟要求等。
•自定义控制信息： Metadata 可以用来传递自定义的控制信息，如安全策略、路由决策等。
如何配置 Metadata在 OVS 中，可以通过以下方式来配置 Metadata：1.编程接口：在 OVS 提供的编程接口中，可以通过设置相应字段的值来配置 Metadata。
2.命令行工具： OVS 提供了一些命令行工具（如ovs-ofctl、ovs-dpctl等），可以使用这些工具来配置Metadata。
oc 初始化结构体
oc 初始化结构体OpenShift(简称oc)是一个基于Kubernetes的容器编排平台，用于开发，部署和管理应用程序。
OpenShift与Kubernetes一样，具有自动化、容错和扩展性的优势。
除此之外，OpenShift还具有应用程序构建、部署、监视和扩展的功能。
OpenShift提供了多种方式来设置应用程序，其中一种方式是使用YAML文件中的结构体。
本文将介绍使用结构体来初始化OpenShift中的应用程序。
结构体是一种自定义的数据类型，它由多个数据元素构成，可以包含基本类型的数据（如整型、浮点型、字符型等）和复合类型的数据（如数组、结构体等）。
在OpenShift 中，结构体可以用来初始化应用程序的对象和属性。
OpenShift中的结构体和在其他编程语言中的结构体类似，它定义了一个由属性组成的对象，并将属性类型、名称和值进行了定义。
在OpenShift中，结构体用于定义应用程序的对象，以及它们的属性和值。
结构体中的属性可以通过标记名称来访问。
下面是一个使用结构体来初始化应用程序的示例：这是一个名为“test-pod”的Pod的结构体定义。
在该结构体中，定义了应用程序的名称、镜像以及运行命令。
下面将分别介绍这些元素的含义：apiVersion - 表示使用API的版本，指定一个特定的API组。
kind - 表示要创建的对象类型，可以是Pod，Deployment等。
metadata - 表示对象的元数据，包括名称和标签。
name - 表示应用程序的名称，必须是唯一的。
spec - 表示应用程序的规范，包括运行镜像、资源限制以及环境变量等信息。
image - 指定要运行的镜像。
使用结构体来初始化OpenShift应用程序的好处在于，可以方便地定义应用程序的对象、属性和值，并且可读性较高。
此外，在使用结构体时，可以重用定义，从而减少代码冗余和错误。
在OpenShift中，还有许多其他的结构体定义，包括DeploymentConfig、Service、Route等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
重点学科网络资源导航库元数据规范1说明本元数据规范是基于科技部立项、上海图书馆起草的《网络资源元数据规范》制订的。
CALIS重点学科导航库建设的目的在于“将因特网中相关重点学科的最优秀的网站信息提供给读者，帮助高校科研人员快速、准确地获取所需信息”。
因此重点学科网络资源导航库是把有用的学术类的网络资源按照学科分类进行搜集归类。
本元数据规范是按照导航库的需要设计的。
本元数据分为两种类型，即描述性元数据和管理性元数据，其中描述性元数据是按照《网络资源元数据规范》，并且根据导航库的需要，选择其中的15个核心元素，其中对元素的修饰词进行适当的扩展。
比如题名增加了缩略提名和并列题名。
对于其非核心元素则没有采用，是根据学科导航苦的特点自行设计了导航库的核心元素和个别元素。
管理性元数据是按照导航库的需要自行设计的。
本方案的设计相关规则也是按照《网络资源元数据规范》的规定，比如其扩展原则与《网络资源元数据规范》的扩展原则一致，即元数据的横向扩展规则遵守核心元素、资源类型核心元素、个别元素的结构组成；元数据的纵向扩展规则采用DC修饰词扩展的方式，不再使用子元素、属性，同时遵循dumb－down（向上兼容）原则。
2著录对象及单位由于重点学科导航库建设的目的是将网络资源中相关重点学科的最优秀的网站信息搜集起来，因此对其的著录对象规定如下：• 只处理有URL且能用HTML显示的网页资源，需要浏览器特定插件或者其他程序支持方可显示的资源也包括在内，如PDF文档、word文档、PPT文档等。
• 在万维网(World Wide Web )上可公开访问的资源；• 各高校FTP服务器上的有关学术资源重点学科导航库的著录单位根据网络资源的特点，分为以下四种情况：1. 以网站为一个著录单位；2. 以网页为一个著录单位；3. 以具体的文件或者软件为一个著录单位；4. 其他3元数据结构和定义本规范中元素的定义采用与Dublin Core一致的方法，即采用ISO/IEC 11179标准，按以下10个方面定义元素：V名称（Name）：元素名称V标识（Identifier）：元素唯一标识V版本（Version）：产生该元素的元数据版本V注册机构（Registration Authority）：（注册元素的授权机构）V语言（Language）：元素说明语言定义（Definition）：对元素概念与内涵的说明V选项（Obligation）：说明元素是限定必须使用的还是可选择的（必备性）V数据类型（Datatype）：元素值中所表现的数据类型V最大使用频率（Maximum Occurrence）：元素的最大使用频次（可重复性）V注释（Comment）：元素应用注释。
为了便于广泛使用，上述十个属性中的下面5个可以取固定值，例如：1）版本：12）语言：中文3）注册机构：4）数据类型：字符串5）最大使用频率（可重复性）：不限修饰词也参照这个方法定义，并在注释项说明修饰词的元素（参见DCMI）：V名称（Name）：修饰词的唯一标识V标签（Label）：修饰词的人工可读标签V定义（Definition）：对修饰词概念与重要性质的说明V注释（Comment）：对该修饰词的注释参见（See Also）：关于此修饰词更多信息的链接导航库元数据结构分为2个部分：–描述性元数据：18个元素–管理性元数据：7元素3.1 描述性元数据表1 描述性元数据列表核心元素（15个）导航库核心元素（2个）个别元素（1个）题名（Title）学科（Discipline）推荐级别（recommendationlevel）创建者（Creator）版本（edition）主题和关键词（Subject andKeywords）其他责任者（Contributor）出版者（Publisher）描述（Description）日期（Date）格式（Format）资源类型（Resource Type）资源标识符（ResourceIdentifier）来源（Source）语种（Language）相关资源（Relation）覆盖范围（Coverage）权限管理（RightsManagement）表2 修饰词列表元素名称元素修饰词编码体系限定词题名交替题名、并列题名、缩略题名创建者创建者单位、创建者联系方式、创建者译名、责任方式主题和关键词 LCSH、MESH、DDC、LCC、UDC、CT(注：汉表)，CLC(注：中图法)，LASC(注：科图法)其他责任者其他责任者单位、其他责任者联系方式、其他责任者译名、责任方式出版者出版地、出版者单位、出版者联系方式、出版者译名、出版方式描述摘要、目录日期资源最近修改日期、资源可获取日期W3CDTF格式IMT资源类型资源标识符URI、SICI、ISBN、ISSN、EISBN、EISSN、DOI来源URI、SICI、ISBN、ISSN、EISBN、EISSN、DOI语种ISO639-2、RFC1766相关资源组成部分，部分为，版本继承，版本关联，格式转换于，格式转换为，被参照，参照，被需求，需求，被替换，替换覆盖范围覆盖空间，覆盖时间 DCMIPeriod、WDC-DTF，DCMI地理位置、DCMI框图、ISO3166、TGN权限管理学科学科门类，一级学科，二级学科版本推荐级别元素定义：1，名称：题名标识：题名（Title）定义：赋予资源的名称。
属性：必备注释：一般指资源对象正式公开的名称。
元素修饰词：交替题名、并列题名、缩略题名2，名称：创建者标识：创建者（Creator）定义：创建资源内容的主要责任者属性：可选注释：创建者的实例包括个人，组织或某项服务。
一般而言，用创建者的名称来标识这一条目。
元素修饰词：创建者单位、创建者联系方式1、创建者译名、责任方式3，名称：主题和关键词标识：主题和关键词(Subject and Keywords)定义：资源内容的主题描述属性：必备注释：通常是指描述学科资源内容的关键词、主题词或分类号。
编码体系修饰词：LCSH、MESH、DDC、LCC、UDC、CT、CLC、LASC4，名称：其他责任者标识：其他责任者（Contributor）定义：对资源的内容作出贡献的其他实体属性：可选注释：其他责任者的实例可包括个人、组织或某项服务。
一般而言，用其他责任者的名字来标识这一条目。
元素修饰词：其他责任者单位、其他责任者联系方式2、其他责任者译名、责任方式5，名称：出版者标识：出版者（Publisher）定义：使资源成为可以获得并可用的责任者属性：可选注释：出版者的实例包括个体，组织，或服务。
一般而言，应该用出版者的名称来标识这一条目。
元素修饰词：出版地、出版者单位、出版者联系方式3、出版者译名、出版方式6，名称：描述标识：描述（Description）定义：资源内容的解释属性：必备注释：说明可以包括但不限于以下内容：文摘、目录、对以图形来揭示内容的资源而言的文字说明、或者一个有关资源内容的自由文本描述。
1比较全面的规定如下：若为个人，包括：姓名、电子邮件、家庭传真、家庭电话、家庭地址、工作头衔、单位传真、单位电话、单位地址；若为团体机构，包括：机构所在、机构所在国家、所在机构的具体部门、机构电子邮件、机构传真、机构电话、机构详细地址；2同“创建者联系方式”元素修饰词：摘要、目录7, 名称：日期标识：日期(Date)定义：与资源生命周期中的一个事件相关的时间属性：可选注释：一般而言，日期应与资源的创建或出版日期相关。
建议采用的日期格式应符合ISO 8601 [W3CDTF]规范，并使用YYYY-MM-DD的格式。
参照：[W3CDTF] /TR/NOTE-datetime元素修饰词：资源最近修改日期、资源可获取日期编码体系修饰词：W3CDTF8，名称：格式标识：格式(Format)定义：资源的物理或数字表现形式属性：可选注释：一般而言，格式可能包括资源的媒体类型或资源的大小，格式元素可以用来决定展示或操作资源所需的软硬件或其他相应设备，例如大小包括资源所占的存储空间及持续时间。
建议采用来自于受控词表中的值，（例如Internet媒体类型[MIME]定义计算机媒体格式）。
编码体系修饰词：IMT9, 名称：资源类型标识：资源类型(Resource Type)定义：资源内容的特征或类型属性：必备注释：《CALIS网络资源类型设定表》10, 名称：资源标识符标识：资源标识符(Identifier)定义：在特定的范围内给予资源的一个明确的标识属性：必备注释：根据一个正式的标识系统，使用一个字符串或数字识别资源。
正式的标识系统包括URI、URL、DOI等。
编码体系修饰词：URI、SICI、ISBN、ISSN、EISBN、EISSN、DOI11，名称：来源标识：来源（Source）定义：现有资源来源的参照属性：可选注释：当前资源可能部分或全部源自该元素所标识的资源，建议对这一资源的标识采用一个符合正式标识系统的字串及数字组合。
12，名称：语种标识：语种（Language）定义：描述资源知识内容的语种属性：必备注释：建议本元素的值采用RFC 3066[RFC3066]，该标准与ISO 639 [ISO639]一起定义了由两个和三个英文字母组成的主语言标签和子标签例如包括“en”或“eng”来表示English, "akk" 来表示Akkadian, "en-GB"表示英国英语。
编码体系修饰词：RFC 306613，名称：相关资源标识：相关资源（Relation）定义：所涉及的相关资源属性：可选注释：著录相关资源时，建议使用符合正式标识系统的字符串或者数字。
元素修饰词：组成部分，部分为，版本继承，版本关联，格式转换于，格式转换为，被参照，参照，被需求，需求，被替换，替换14，名称：覆盖范围标识：覆盖范围（Coverage）定义：资源内容所涉及的外延与覆盖范围属性：可选注释：覆盖范围一般包括空间位置（一个地名或地理坐标）、时间区间（一个时间标识，日期或一个日期范围）、或者权限（比如命名的授权实体）推荐覆盖范围最好是取自于一个受控词表（例如地名词库[TGN]），并应尽可能地使用由数字表示的坐标或日期区间来描述地名与时间段。
参照：[TGN] /research/tools/vocabulary/tgn/index.html元素修饰词：覆盖空间，覆盖时间，覆盖地区编码编码体系修饰词： W3C-DTF15，名称：权限管理标识：权限管理（Rights）定义：关资源本身所有的或被赋予的权限信息属性：可选注释：通常是指有关资源权限管理的声明，或者对服务机构提供该资源的参照。
权限管理包括知识产权、版权和其它产权。