The document discusses the DCMI Metadata Framework, which includes the DCMI Abstract Model (DCAM) and other components. DCAM defines core metadata constructs like properties and vocabularies, and provides a basis for defining interoperable vocabularies, profiles, and syntaxes. It also discusses challenges around cross-framework interoperability and terminology used for different types of metadata specifications.

1. The DCMI Metadata Framework DCMI Abstract Model Vocabularies Application Profiles Mikael Nilsson <mikael@nilsson.name>

2. The DCMI Metadata Framework Fundamental notion: the one-to-one principle ” One resource – one description” History: 1994: 15 ”core” elements 2000: Qualifiers => need for a model 2002: Grammatical principles 2005: DCMI Abstract Model

3. DCMI Abstract Model Defines the core constructs used in DC metadata: properties , vocabulary encoding schemes, etc... Refined and formalized version of the “DCMI Grammatical Principles” Built on the one-to-one principle Basis for defining vocabularies, profiles and syntaxes Basis for interoperability with other initiatives RDF & the Semantic Web IEEE LOM etc.

4. Basic structure of DCAM Value Resource Property Property/value pair Non-literal Literal

5. The Manzanillo Framework

6. Creating metadata using DCAM Description Set Profile Description Set Metadata record Interoperable interpreter transfer usage DMCI Abstract Model Functional Requirements Vocabulary (existing and new) Domain Model (Entities and relationships) Resources Syntax

7. Remaining Questions 1: What is RDA? Framework? Abstract Model? Vocabulary? Application Profile? Syntax?

8. Remaining Questions 2: Who's RDA for? Librarians? Application developers? Database managers? Users? Vocabulary creators? Application Profile creators?

9. The ”values” of the DCAM Two sorts: Values ”in” the description itself = Literals (not the same as value strings) Other values Literal = string + language or datatype (=SES) Non-literals are described ” inline” by 0 - 1 URI for identification 0 – 1 VES for identifying controlled vocabulary 0 – many value strings (= string + language or datatype) in a separate description

10. Interoperability for DC metadata Reusing existing properties... in new application profiles in new syntaxes Adding new properties to... existing application profiles existing syntaxes Introducing new values to existing properties Expressing existing APs in new syntaxes

11. Vocabulary Model (elements) Example: http://dublincore.org/documents/dcmi-terms/

12. Vocabulary Model (values) No real consensus on how to describe value vocabularies. Value vocabularies come in many kinds simple lists thesauri taxonomies ontologies etc. SKOS?

13. Profile Model Example: CEN/ISSS CWA 14855

14. Where we are (DC family)

15. Where others are (IEEE LOM family)

16. Where others are (RDF family)

17. Cross-framework interoperability How about interoperability between DC <==> IEEE LOM <==> RDF <==> MPEG-7 etc.? All follow the same basic pattern BUT – very different abstract models In general: cross-framework is hard DC <==> RDF works – as models are intentionally compatible See also “ The Future of Learning Object Metadata Interoperability” , in Koohang A. (ed.) Learning Objects: Standards, Metadata, Repositories, and LCMS, in press.

18. Terminology Stop using “metadata standard” or “schema” Start using either abstract model metadata format/syntax metadata vocabulary application profile “ What kind of specification am I trying to produce?” Most: application profile (+ some vocabulary)

19. Take home message Formalized models (DCAM, vocabs, profiles) pave the way for interoperable processing A clear framework helps us fill in the blanks Much progress over the last year! See DC-ARCH... The word ”schemas” is overused...