《元数据抽象模型和新加坡框架》由会员分享，可在线阅读，更多相关《元数据抽象模型和新加坡框架（26页珍藏版）》请在金锄头文库上搜索。
1、主要内容DC元数据标准规范体系体系DC元数据抽象模型DC元数据新加坡框架：应用纲要的规范形式说明：Google图片搜索对此slide亦有贡献DC元数据标准规范体系Element | DCMES, DCQElement |DCAMDCAP (DCTerms+) DC1.0 DC2.0DC1.0Elements元素Qualifiers修饰词lElementRefinements元素修饰词(子元素)lEncodingSchemes编码体系修饰词VocabularyEncodingSchemes词表编码体系SyntaxEncodingSchemes语法编码体系参见:/dublincore.org/us
2、age/documents/principles/#elementDC应用纲要1.0CWA14855定义指南性文档没有对于元数据编码的任何规定不支持DCAM不支持DescriptionSet(描述集)DC眼中的世界(DCAM)任何事物都是资源l资源有类型l任何资源都可以以URI标识任何资源都有属性l属性词即元数据l属性词表即元数据方案l元数据方案可有多种形式：不/半/规范的l应用纲要是一种正在成型的半/规范形式任何属性都有属性值属性值有领域和范围(domain&range)属性值可以是另一个资源，可以是文字(literal)l取值的规范控制，即各类KOS，也是元数据DCMI类型词表(DCTYP
3、E)DC元数据描述的资源对象可能存在的类型：CollectionDatasetEventImagelMovingImagelStillImageInteractiveResourcePhysicalObjectServiceSoftwareText“资源”的唯一必备属性：URIURI:UniformResourceIdentifier(RFC3986定义)唯一必备功能：标识资源(无论是物理的还是抽象的)；包含三部分：l访问资源的命名机制l存放资源的主机名l资源自身的名称，由路径表示两种类型：lURL如：news:comp.lang.javalURN如：urn:isbn:096139210xur
4、n:doi:10.1045/november2007-kaufmanURI是抽象类，并不规定解析进一步说明1.元数据是一种人工语言（消除歧义、明确定义、人机共读）；2.元数据元素集是描述资源各个方面的属性词表；3.元数据取值如果规定只能从某些词表中选取，这些词表就属于受控的规范词表；这属于元素取值的domain和range；4.元数据应用纲要是为了领域应用而制订的元数据方案的一种表达形式，目前正在成为规范的，叫做“DC元数据应用纲要”，核心是符合DC抽象模型的元数据形式化表述（也就是一种机读形式），通常可以以RDF形式表达；5.应用模型（规定应用领域的各类实体及其相互关系）、著录规则等文档，也
5、可以成为元数据应用纲要的组成部分；6.元数据注册系统可以作为元数据元素的命名域管理体系而存在，但命名域并非一定需要注册系统进行管理；7.元数据元素词表，包括规定元数据取值的规范词表，都可以看成是一种人工语言，每个术语都应该被赋予唯一的URI，都可以通过注册系统进行管理；8.元数据形式化的表达必须采用基于XML的RDF或OWL等的Schema，著录工作单当然可以通过完整表达元数据方案各种关系和约束的schema来自动生成，并进行校验。当然这需要一定的环境和软件工具来实现Resource haspropertyDC:CreatorDC:TitleDC:SubjectDC:Date.X主语谓词属性词
6、属性值optional qualifieroptional qualifier修饰/限定词来自(from)：Stuart WeibelResource hasDate2000-06-13RevisedISO8601Resource hasSubjectLanguages - GrammarLCSH来自(from)：Stuart WeibelDC属性元素的“领域和范围(Domain and Range)”见： :/dublincore.org/documents/domain-range/index.shtmlRecord(encodedashtml,XML,orRDF/XMLDescripti
7、onsetResourceDescription(URI)ResourceDescription(URI)ResourceDescription(URI)StatementStatementStatementlanguage(pt-BR)DCAM图示(来自Andy Powell)valuestringvalueURIproperty(URI)syntaxencodingschemeVocabularyencodingscheme新加坡框架进一步定义了DC应用纲要符合DC抽象模型(DCAM)的应用纲要(“DC应用纲要”)包含如下一系列文档：功能需求说明(必须desirable)领域模型(应有ma
8、ndatory)元素集描述元素集描述(DSP)(应有mandatory)应用指南(可选)编码句法指南(可选)应用指南功能需求领域模型元素集描述编码指南与数据格式社区领域模型元素词表DCMI抽象模型DCMI句法指南RDF/SRDF标注 Annotate建立基础建立基础建立基础使用使用建立基础建立基础建立基础建立基础建立基础建立基础基础标准领域标准DC应用纲要新加坡框架图示(来自Tom Baker)描述集纲要(DSP)定义了描述集在结构方面的约束:l允许出现怎样的描述l允许采用怎样的属性l怎样的属性值聚合方式以XML表达(RDF当然是XML)忽略元素的定义(通过URI参考)忽略版本控制不要求应用指
9、南著录规范等给人读的文档翻译、修改自MikaelNelsson的演讲稿参见：:/dublincore.org/architecturewiki/DescriptionSetProfile当前元数据研究和应用中的问题 人读而非机读语义的模糊性模型的完整性(两类模型：FRBR和DCAM)执行的一致性数据的独立性基本上无法编码实现（包括数据库系统开发）我们目前的元数据方案可以说只完成了MARC数据格式的定义，还没有2709格式使其真正机器可读从这一点来说，目前各类元数据著作、方案中值得推敲的地方还是比较多的一些建议建立本地化扩展术语的命名域参考建立元数据应用纲要(词表)及编码的登记注册体系修订目前的
10、领域应用元数据应用纲要推进元数据集成开发系统(IDE)软件和工具的开发建立数字图书馆标准规范的开放讨论维护机制“机读版”元数据方案的推广、培训随着元数据应用的开展和普及，一致性问题越来越严重。现在如果不重视，将后患无穷！问题讨论元素名是否应该翻译？dc:creator“Verfasser”标签“Creator”标签“创建者”标签Server inGermanyServer in CASDCMI Server（上图改编自Stuart Weibel有关演示文稿） 元素名只是一个机器识别的符号(Token)而已 一个符号(token)，多种翻译(labels) 如果翻译了，就不是DC了 (“盗版DC
11、“？)元数据“记录”是怎样的结构？过去称为记录的，多为现在所称的描述描述l平面化(MARC中的记录)l“虚拟记录”l传统结构：数据库记录-文件系统l描述/描述集1:1原则是针对描述而言，而非记录描述/描述集可以通过不同的记录形式/格式来实现DCAM打散了资源描述，在具体应用中如何实现？DCAM是一个抽象模型，不考虑具体实现（如记录的统一、聚类等）；DCAM提供需求分析、功能设计的思路和方法，应用系统可以采用任何方式实现功能；目前URI是一切Web资源描述的基础，包括URL和URN两类。URN(eg:DOI/ISBN，甚至各类词表)如何实现全局解析，不是Web的事情，是行业应用的事情；URI不是完美的资源标识方法，新的方法正在研讨中编码问题JohnDoe15891670主要问题：元数据描述集/元数据描述1:1Token的应用：dc.creator,dcterms.date元素的扩展：name（是否是FOAF的name?）嵌套表示是否值得推荐？编码体系修饰词的采用(如：W3CDTF)元数据抽象模型与新加坡框架谢谢！欢迎访问DC中文网：:/dublincore/
