SlideShare a Scribd company logo

DC-2008 Architecture Forum Open session

Mikael Nilsson, profile picture
Mikael Nilsson

The document discusses the goals and major specifications of the DCMI Architecture Forum. It aims to document the DCMI metadata framework, develop technical specifications, and provide feedback on technical issues. Major specifications discussed include the DCMI Abstract Model, expressions for expressing DCMI metadata in different formats like RDF and XML, and the Singapore Framework for DC Application Profiles. It also discusses different levels of interoperability and introduces Description Set Profiles as a way to formally represent the constraints of a Dublin Core Application Profile.

EducationTechnology
1 of 94
Downloaded 19 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
Architecture Forum Open session Mikael Nilsson < [email_address] >
Major goals of the Architecture Forum Document the DCMI metadata framework Develop technical specifications Provide feedback on technical issues To DCMI users To other DCMI communities To the Usage Board Serve as a platform for discussions and evaluations of future technical directions
Major specifications from DC-ARCH DCMI Abstract Model (2005, 2007) Underlying model for DCMI metadata Defines notions of Property Vocabulary Encoding Scheme Syntax Encoding Scheme Etc ... and how they fit together Used as basis for metadata expressions Used as basis for how DCMI terms are defined
Understanding the model Literal and non-literal values “ Description sets” vs “records” “ Values” vs “value strings” and URIs “ Domain model” of described entities
Who needs to understand what? Application architects (who implement) To follow model, need to know all of the above! Understand how formats express the model Non-expert users (who define requirements) Examples of common design patterns Simple question trees for narrowing choices Palette of pre-defined well-engineered choices
Guidelines for profile designers Guidelines for Dublin Core Application Profiles Palette of profile snippets to cut-and-paste? Wiki format convertible into XML Library of usage templates?
Major specifications from DC-ARCH DCMI Metadata expressions DC-RDF (2008) Replaces DCQ-RDF-XML (2002) and DCMES-XML (2002) DC-HTML (2008) Replaces DCQ-HTML (2003) DC-DS-XML (200?) Might replace DC-XML (2003) DC-TEXT (2007) A simple human-readable text format (not for machine processing)
Major specifications from DC-ARCH Singapore Framework for DC Application Profiles (2008) Description set profiles (200?) - working draft Interoperability levels for Dublin Core metadata
The Singapore Framework In Singapore, at DC2007, a new definition of a “Dublin Core Application Profile” was introduced A “DC Application Profile” is packet of documentation which consists of: Functional requirements (mandatory) Domain model (mandatory) Description Set Profile (DSP) (mandatory) Usage guidelines (optional) Encoding syntax guidelines (optional)
Profiles and standards Profiles are based on domain standards: Standard metadata vocabularies (e.g., Dublin Core elements) Standard domain models (e.g., FRBR) Functional Requirements for Bibliographic Records A standard record model (DCMI Abstract Model) Foundation is Resource Description Framework (“Semantic Web”) RDF is the model underlying the DCMI Abstract Model RDF Schema is the model underlying the machine processable definitions of terms
The Singapore Framework
The Singapore Framework Foundation standards Domain standards Application Profile
Interoperability Levels for Dublin Core metadata Level 1: Informal interoperability Shared concepts with natural-language definitions No use of formal models or term URIs Test: Is there a mapping to shared elements? Example: IEEE LOM reuses some definitions and maps to 15-element “Dublin Core” (ISO 15836)
Interoperability Levels for Dublin Core metadata Level 2: Semantic Interoperability Correct use of formal RDF graph model with conformant vocabularies (eg DCMI Metadata terms) Use of URIs and formal semantic relationships between terms (eg subproperties) Test: Is there a mapping to RDF triples? Examples: All RDF data (by definition) All RDF data extracted from non-RDF formats (eg via GRDDL transforms) All XHTML or HTML data using RDFa or DC-HTML/2008.
Interoperability Levels for Dublin Core metadata Level 3: Description set syntactic interoperability Level-2-compatible data packaged in bounded description sets (records) as per DCMI Abstract Model (DC-AM) Conventions for citing vocabulary encoding schemes (controlled vocabularies) Test: Is there a mapping to “Expressing Dublin Core metadata using the DC-Text format”? Examples: All data using DC-AM-compatible specifications, such as DC-DS-XML.
Interoperability Levels for Dublin Core metadata Level 4: Description Set Profile Interoperability Level-3-compatible data that follows the specification “Description Set Profiles: A constraint language for Dublin Core Application Profiles” Additional interoperability via shared Functional Requirements and Domain Model (“Singapore Framework for Dublin Core Application Profiles”) Test: Is there a mapping to DSP constraints? Examples: Scholarly Works Application Profile
Interoperability Levels for Dublin Core metadata Level 4: Description Set Profile Interoperability Level 3: Description Set syntactic interoperability Level 2: Semantic interoperability Level 1: Informal interoperability
Mikael Nilsson < [email_address] > DC 2007, Singapore Aug 27-31, 2007 Description Set Profiles
DC Application Profiles - traditional definition “ A Dublin Core Application Profile (DCAP) is a declaration specifying which metadata terms an organization, information provider, or user community uses in its metadata. By definition, a DCAP identifies the source of metadata terms used—whether they have been defined in formally maintained standards such as Dublin Core, in less formally defined element sets and vocabularies, or by the creator of the DCAP itself for local use in an application. Optionally, a DCAP may provide additional documentation on how the terms are constrained, encoded or interpreted for application-specific purposes.” -- CEN CWA 14855:2003
Machine-readable constraints? XML Schema? Not applicable to RDF Not applicable to HTML Not applicable to .... CEN Guidelines Not based on DCAM No support for Description Sets Needed something new “ Dublin Core Description Set Profile”
Envisioned usages as a formal representation of the constraints of a Dublin Core Application Profile as configuration for databases as configuration for metadata editing tools etc.
Scope of a DSP spec Information model: Structural constraints on a description set: what descriptions may occur what properties may be used what ways might a value surrogate be given XML expression
Out of scope Human-readable documentation Definition of vocabularies Version control etc.
DC Application Profiles - new definition (in progress) A DCAM-conformant Application Profile (“DC Application Profile”) is packet of documentation which consists of: Functional requirements (mandatory) Domain model (mandatory) Description Set Profile (DSP) (mandatory) Usage guidelines (optional) Encoding syntax guidelines (optional)
 
Foundation standards Domain standards Application Profile
First working draft http://dublincore.org/architecturewiki/DescriptionSetProfile Comments on DC-ARCHITECTURE Publication schedule not defined
Example: The book AP A book: a literal title a creator, described separately A creator a literal name
Statement template: literal title dcterms:title Literal value Language SES Property: Statement template: creator dcterms:creator Value string Language SES Property: Value URI Vocabulary Encoding Scheme Description reference: Creator Statement template: literal name foaf:name Literal value Language SES Property: standalone:no Description Template: Book Description Template: Creator
{{{#!DSP == Description template: Book == DT=(min=&quot;1&quot; max=&quot;1&quot; standalone=&quot;yes&quot; identifier=&quot;book&quot;) === Title === ST=(max=&quot;1&quot; type=&quot;literal&quot; PC={http://purl.org/dc/terms/title}) || Definition || A name given to the resource. || LC=(LangC=(occurrence=&quot;optional&quot;) SESConstraint=(occurrence=&quot;disallowed&quot;) ) === Creator === ST=(max=&quot;1&quot; type=&quot;nonliteral&quot; PC={http://purl.org/dc/terms/creator}) || Definition || An entity primarily responsible for making the resource. || NLC=(VURIConstraint=(occurrence=&quot;disallowed&quot;) VESConstraint=(occurrence=&quot;disallowed&quot;) VStringConstraint=(max=&quot;1&quot; LangC=(occurrence=&quot;disallowed&quot;) SESConstraint=(occurrence=&quot;disallowed&quot;)) description=&quot;creator&quot; ) == Description template: Creator == DT=(min=&quot;1&quot; max=&quot;1&quot; standalone=&quot;no&quot; identifier=&quot;creator&quot;) === Name === ST=(max=&quot;1&quot; type=&quot;literal&quot; PC={http://xmlns.com/foaf/0.1/name}) || Definition || A name for some thing. || LC=(LangC=(occurrence=&quot;disallowed&quot;) SESConstraint=(occurrence=&quot;disallowed&quot;) ) }}} http://knowware.nada.kth.se/DCWiki/TheBookAP?action=raw http://knowware.nada.kth.se/DCWiki/TheBookAP http://knowware.nada.kth.se/DCWiki/TheBookAP?action=DSP2XML Link
http://knowware.nada.kth.se/DCWiki/TheBookAP?action=raw http://knowware.nada.kth.se/DCWiki/TheBookAP http://knowware.nada.kth.se/DCWiki/TheBookAP?action=DSP2XML
<?xml version=&quot;1.0&quot;?> <DescriptionSetTemplate> <DescriptionTemplate maxOccur=&quot;1&quot; minOccur=&quot;1&quot;> <StatementTemplate maxOccur=&quot;1&quot; type=&quot;literal&quot;> <Property>http://purl.org/dc/terms/title</Property> <LiteralConstraint> <SyntaxEncodingSchemeOccurrence>disallowed</SyntaxEncodingSchemeOccurrence> <LanguageOccurrence>optional</LanguageOccurrence> </LiteralConstraint> </StatementTemplate> <StatementTemplate maxOccur=&quot;1&quot; type=&quot;nonliteral&quot;> <Property>http://purl.org/dc/terms/creator</Property> <NonliteralConstraint descriptionTemplateID=&quot;creator&quot;> <ValueURIOccurrence>disallowed</ValueURIOccurrence> <VocabularyEncodingSchemeOccurrence>disallowed</VocabularyEncodingSchemeOccurrence> <ValueStringConstraint maxOccur=&quot;1&quot;> <SyntaxEncodingSchemeOccurrence>disallowed</SyntaxEncodingSchemeOccurrence> <LanguageOccurrence>disallowed</LanguageOccurrence> </ValueStringConstraint> </NonliteralConstraint> </StatementTemplate> </DescriptionTemplate> <DescriptionTemplate maxOccur=&quot;1&quot; minOccur=&quot;1&quot;> <StatementTemplate maxOccur=&quot;1&quot; type=&quot;literal&quot;> <Property>http://xmlns.com/foaf/0.1/name</Property> <LiteralConstraint> <SyntaxEncodingSchemeOccurrence>disallowed</SyntaxEncodingSchemeOccurrence> <LanguageOccurrence>disallowed</LanguageOccurrence> </LiteralConstraint> </StatementTemplate> </DescriptionTemplate> </DescriptionSetTemplate> http://knowware.nada.kth.se/DCWiki/TheBookAP?action=raw http://knowware.nada.kth.se/DCWiki/TheBookAP http://knowware.nada.kth.se/DCWiki/TheBookAP?action=DSP2XML
Putting DSPs to work The SHAME demo Takes DSP-XML Generates an RDF editor on the fly RDF conforms to DSP constraints
The speaker PhD student at Royal Inst. of Technology, Stockholm Subject: Metadata Standardization and Interoperability Engaged in metadata within IEEE, ISO, DCMI Co-chair of DC Architecture Forum Joint DCMI / IEEE LTSC Taskforce Co-author of DCMI Abstract Model Expressing Dublin Core in RDF Singapore Framework for DC Application Profiles
Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
Metadata specifications outside of DCMI Many domains: E-Government Education Geospatial information Libraries Business Multimedia Geospatial information etc.
Metadata specifications outside of DCMI Many technical environments Low-level (file systems, protocols etc) File formats (HTML, Atom, etc.) Ontologies (OWL, etc.) Repositories Harvesting
Metadata specifications outside of DCMI Many expressions XML RDF SQL HTML ID3 EXIF
Metadata specifications outside of DCMI Many complete “schemas” MARC METS MODS IEEE LOM MPEG-7 CSDGM etc.
Metadata specifications outside of DCMI Many purposes Search Describe Administrate Structure etc.
“Interoperable with Dublin Core”? What does it take to be called interoperable? Specific domain? NO Specific technical environment? NO Specific expression? NO Specific complete “schema”? Not really... Specific purpose? NO But seriously...? ...we obviosly need to talk about the term “ interoperability”
Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
The elusive notion of interoperability IEEE definition of interoperability: “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.” DCMI has four notions of “use the information”: Use the documented definition of the DCMI terms Use the machine-processable semantics of terms Use the structure of the metadata record Use the constraints in an application profile Each usage leads to a different notion of interoperability
DCMI specifications for interoperability Textual definition of the DCMI terms: DCMI Metadata Terms Machine-processable semantics of terms: DCMI Abstract Model RDF expression of Dublin Core metadata RDF schemas for DCMI terms Metadata records DCMI Abstract Model - “description sets” DCMI expressions: XML, (X)HTML, etc. Application profiles Singapore Framework Description Set Profiles
Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
Human semantics for Dublin Core The Dublin Core terms have carefully crafted definitions Example: Label: Creator Definition: An entity primarily responsible for making the resource. Comment: Examples of a Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity. The meaning of these terms is well understood Therefore, we often see compatible definitions used in other specifications The 15 elements in the “Dublin Core Metadata Element Set” are most often reused
Example: IEEE LOM IEEE LOM is the major metadata specification used for Learning resources 1.6 Coverage The time, culture, geography or region to which this learning object applies. The extent or scope of the content of the learning object. Coverage will typically include spatial location [...] NOTE —This is the definition from the Dublin Core Metadata Element Set, version 1.1
Example: The Atom Syndication Format Atom (like RSS) is used for content syndication (news feeds, podcasts etc.) The &quot;atom:rights&quot; element is a Text construct that conveys information about rights held in and over an entry or feed. (RFC 4287) Cf. the Dublin Core term “Rights”: “Information about rights held in and over the resource.”
Uses of human semantics Compatible reuse of Dublin Core element semantics implies: Well-understood definitions Easier to input metadata Easier to process metadata Definitions interoperable with other metadata specifications Less work to design a metadata specification Easier to create crosswalks Etc. Human semantics often sufficient for limited locally scoped projects
Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
Dublin Core in the wild: The Semantic Web The DCMI Terms carry machine-readable definitions as well: <rdf:Description rdf:about=&quot; http://purl.org/dc/terms/creator &quot;> <rdfs: label xml:lang=&quot;en-US&quot; > Creator </rdfs:label> <rdfs: comment xml:lang=&quot;en-US&quot; > An entity primarily responsible for making the resource. </rdfs:comment> <dcterms: description xml:lang=&quot;en-US&quot; > Examples of a Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity. </dcterms:description> <rdfs: isDefinedBy rdf:resource=&quot; http://purl.org/dc/terms/ &quot;/> <dcterms: issued > 2008-01-14 </dcterms:issued> <dcterms: modified > 2008-01-14 </dcterms:modified> <rdf: type rdf:resource=&quot; http://www.w3.org/1999/02/22-rdf-syntax-ns#Property &quot;/> <dcterms :hasVersion rdf:resource=&quot; http://dublincore.org/usage/terms/history/#creatorT-001 &quot;/> <rdfs: range rdf:resource=&quot; http://purl.org/dc/terms/Agent &quot;/> <rdfs: subPropertyOf rdf:resource=&quot; http://purl.org/dc/elements/1.1/creator &quot;/> <rdfs: subPropertyOf rdf:resource=&quot; http://purl.org/dc/terms/contributor &quot;/> </rdf:Description>
Terms are referenced by URI Unique identification part of the framework The meaning of terms is carried by the URI No need for manual crosswalks “Context-free” metadata Metadata can be merged, mixed and matched No trouble combining metadata from several sources Usage of terms is restricted by domains and ranges A “Creator” of a resource is always an Agent. Improves processing possibilities “Refinements” are part of the framework A “Vocalist” (marcrel:VOC) of a resource is understood to be “Contributor” (dc:contributor) of the same resource. What happens on the Semantic Web?
Example: Adobe XMP Metadata part of media files (JPEG, PDF, RAW, etc.) Supported in a wide range of Adobe products Mixes Dublin Core properties with EXIF properties PDF properties Etc. < dc:publisher > <rdf:Bag> <rdf:li rdf:parseType=&quot;Resource&quot;> <rdf:value>James Bond</rdf:value> <ns:role>secret agent</ns:role> </rdf:li> </rdf:Bag> </dc:publisher> < tiff:ImageDescription > <rdf:Alt> <rdf:li xml:lang=&quot;x-default&quot;>TIFF image description</rdf:li> <rdf:li xml:lang=&quot;de-DE&quot;>TIFF Bildbeschreibung</rdf:li> </rdf:Alt> </tiff:ImageDescription> < xmpDM:videoFrameSize stDim:w=&quot;16&quot; stDim:h=&quot;9&quot; stDim:unit=&quot;inch&quot;/>
Example: Open Document Format ODF 1.2 (OASIS) introduced RDF-based metadata Supports metadata in Manifest (metadata file) Inline in text of document < bibtex:Article rdf:about=&quot;info:pmid/17445913&quot;> < dc:title >Neuraminidase inhibitor susceptibility[...].</dc:title> < dcterms:abstract >As an intermediate host of avian and [...] .</dcterms:abstract> < dc:creator >K Bauer</dc:creator> <dc:creator>M Schmidtke</dc:creator> < foaf:maker > < foaf:Person rdf:about=&quot;http://purl.org/net/hubmed/ns/pmids/17445913/authors/Bauer,K&quot;> < foaf:name >K Bauer</foaf:name> <rdf:value>K Bauer</rdf:value> <foaf:givenname></foaf:givenname> <foaf:surname>Bauer</foaf:surname> </foaf:Person> </foaf:maker> < dc:identifier >10.1016/j.antiviral.2007.03.007</dc:identifier> < prism:publicationName >Antiviral Res</prism:publicationName> <prism:publicationDate>2007-09</prism:publicationDate> <prism:volume>75</prism:volume> <prism:number>3</prism:number> <prism:startingPage>219</prism:startingPage> <prism:endingPage>226</prism:endingPage> <prism:isPartOf rdf:resource=&quot;urn:issn:0166-3542&quot;/> </bibtex:Article>
Uses of machine semantics The use of a common framework means metadata... from different domains using different vocabularies used in different technical environments... ... can be combined without effort. Ontologies Enable advanced processing of metadata Automatic discovery of term definitions “Follow your nose” Linked open data Giant global graph of metadata
Follow your nose http://xmlns.com/foaf/0.1/knows RDF Schema label comment range HTML http://example.com/persons#john http://example.com/persons#gordon FOAF specification http://xmlns.com/foaf/0.1/knows “ Knows” “ A person known by this person (indicating some level of reciprocated interaction between the parties)” foaf:Person
Linked Open Data More than 2 billion RDF triples
Support for machine semantics in DCMI DCMI Abstract Model Lays the foundations for definition and usage of terms in Dublin Core metadata Builds on RDF RDF schemas for DCMI terms Available in “follow your nose”-compatible way RDF expression of Dublin Core Defines how to express Dublin Core metadata using RDF
Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
Metadata records: structure in the chaos Dublin Core builds on experiences from the library community A strong influence is the “library card” A managable “unit of metadata” On the other hand: the “one-to-one principle” One resource, one description A Book and its author are described separately A Book and a digital copy are described separately The DCMI Abstract Model A formalization of the “library card” for Dublin Core, first formalized in 2005
Why the DCMI Abstract Model? A DCMI-specific definition of “metadata record” A framework for designing metadata records A basis for validation of records A basis for exchange formats for records The DCAM provides A notion of a “description set”( = record) as a collection of descriptions of individual resources. A formalization of earlier practices in the DC community
Example: DC-DS-XML A proposed XML language that provides a generic XML encoding for DC metadata Allows for validation with XML schema Any properties (even non-DC) can be used. <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; ?> <dcds: descriptionSet xmlns:dcds=&quot;http://purl.org/dc/xmlns/2008/09/01/dc-ds-xml/&quot;> <dcds: description dcds: resourceURI =&quot;http://dublincore.org/pages/home&quot;> <dcds:statement dcds:propertyURI=&quot;http://purl.org/dc/terms/title&quot; > <dcds: literalValueString xml:lang=&quot;en-GB&quot;> DCMI Home Page </dcds:literalValueString> </dcds:statement> <dcds:statement dcds:propertyURI=&quot;http://purl.org/dc/terms/publisher&quot; dcds: valueURI=&quot;http://example.org/agents/DCMI&quot; > <dcds:valueString>Dublin Core Metadata Initiative</dcds:valueString> </dcds:statement> <dcds:statement dcds: propertyURI=&quot;http://purl.org/dc/terms/date&quot; > <dcds: literalValueString > 2005-05-05 </dcds:literalValueString> </dcds:statement> </dcds:description> </dcds:descriptionSet>
Example: DC-HTML HTML encoding of metadata records Does not support full version of DCAM Any properties (even non-DC) can be used. <?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?> <!DOCTYPE html PUBLIC &quot;-//W3C//DTD XHTML 1.0 Strict//EN&quot; &quot;http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd&quot;> <html xmlns=&quot;http://www.w3.org/1999/xhtml&quot;> <head profile=&quot;http://dublincore.org/documents/2008/08/04/dc-html/&quot;> <title>Services to Government</title> <link rel=&quot;schema.DC&quot; href=&quot;http://purl.org/dc/elements/1.1/&quot; /> <link rel=&quot;schema.MARCREL&quot; href=&quot;http://www.loc.gov/loc.terms/relators/&quot; /> <meta name=&quot; DC.title &quot; content=&quot; Services to Government &quot; /> <link rel=&quot; MARCREL.EDT &quot; href=&quot; http://example.org/agents/DeptOfObfuscation &quot; /> </head>
Connecting records and semantics Newer DCMI syntaxes support GRRDL from W3C “Gleaning Resource Descriptions from Dialects of Languages” Idea: All XML-based languages can auto-generate RDF data For DCAM-based formats, it's straightforward. Other XML languages are starting to use GRDDL In particular, the Microformats community
Example: From XML to graphs <LearningResource grddl:transform=”http://yyy/mlr.xsl” > <Title>A book</title> <Contribution> <Date>2008-09-03</Date> <Entity> <Name>John Smith</Name> </Entity> </Contribution> </LearningResource> http://yyy/mlr.xsl foaf:name foaf:mbox foaf:knows title contribution date entity name foaf:mbox foaf:knows http://example.com/persons#john “ John Smith” “ [email_address] ” http://example.com/persons#gordon My learning resource Contribution A http://example.com/persons#john “ A book” “ John Smith” “ 2008-09-03” “ [email_address] ” http://example.com/persons#gordon My learning resource Contribution A Person B “ A book” “ John Smith” “ 2008-09-03” title contribution date entity name
Metadata islands... IEEE LOM NorLOM UK LOM Core ... RDF Dublin Core DC APs Semantic Web ... MARC21 MARC-XML METS METS MPEG-7
... and a metadata interoperability vision Education Government Libraries Multimedia Semantic Web
Metadata records in DCMI specifications DCMI Abstract Model Defines “description sets”, the DCMI notion of metadata records DC-DS-XML Encodes general description sets in XML DC-HTML? Supports a single description in HTML/XHTML With a few limitations DC-RDF? Does not represent “records” explicitly
Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
Dublin Core Application Profiles We have a definition of managable records We have the option of global interoperability We have the widely used term definitions What's left? Community interoperability! A particular application, domain or community may want Better documentation of their metadata records More support for quality control / validation This is usually described with Application Profiles
Application Profiles Specifies a community's use of metadata records Defines What things are described? Why? Which properties are used? What kinds of values are used? What vocabularies are referenced? What guidelines for data entry are used? etc.
A word of Warning DCMI uses “application profile” to mean: A specification of which metadata terms are used A specification of how those terms are constrained and interpreted in the local context Other communities use “profile” to mean A customization of an existing schema Starts from a “base” standard, adds context-specifics The two notions are not very interoperable!
The Singapore Framework In Singapore, at DC2007, a new definition of a “Dublin Core Application Profile” was introduced A “DC Application Profile” is packet of documentation which consists of: Functional requirements (mandatory) Domain model (mandatory) Description Set Profile (DSP) (mandatory) Usage guidelines (optional) Encoding syntax guidelines (optional)
Profiles and standards Profiles are based on domain standards: Standard metadata vocabularies (e.g., Dublin Core elements) Standard domain models (e.g., FRBR) Functional Requirements for Bibliographic Records A standard record model (DCMI Abstract Model) Foundation is Resource Description Framework (“Semantic Web”) RDF is the model underlying the DCMI Abstract Model RDF Schema is the model underlying the machine processable definitions of terms
The Singapore Framework
The Singapore Framework Foundation standards Domain standards Application Profile
Functional requirements Describe the functions that the application profile is designed to support as well as functions that are out of scope. Form the basis of evaluating the application profile for internal consistency Gives guidance on the appropriateness of the application profile for a given use.
Example: ePrints Functional requirements Requirement: Provide a richer set of metadata than is currently possible with simple DC Requirement: Be compatible with preservation metadata approaches. Requirement: Support extensibility of the application profile for other types of material. Requirement: Implement an unambiguous method of identifying the full-text(s). Requirement: Support navigation between different 'versions' of the same eprint etc.
Domain models Defines the basic entities described by the application profile and their fundamental relationships. Concretizes the scope for the application profile. The domain model can be expressed using just text or using a more formal approach such as UML. Does NOT say what properties to use
Example: ePrints domain model
Description Set Profiles Defines a set of metadata records that are valid instances of an application profile. The Description Set Profile model is currently being developed within the Dublin Core Architecture Forum Designed to offer a simple constraint language for Dublin Core metadata, based on the DCMI Abstract Model A DSP constrains the resources that may be described by descriptions in a description set conforming to the application profile, the properties that may be used, the ways a value may be referenced.
Description Set Profiles A Description Set Profile can be used for purposes such as: formally representing constraints used in metadata configuring databases configuring metadata editing tools
Example: ePrints DSP
Statement template: literal title dcterms:title Literal value Language SES Property: Statement template: creator dcterms:creator Value string Language SES Property: Value URI Vocabulary Encoding Scheme Description reference: Creator Statement template: literal name foaf:name Literal value Language SES Property: standalone:no Description Template: Book Description Template: Creator
Usage guidelines Usage guidelines describe how to apply the application profile How are the used properties intended to be used in the application context? What principles are used when gathering data? What other principles governs the implementation and use of the application profile
Example: Collections description Guildelines for Title element: Where an existing name is used, the value string should preserve the original wording, order and spelling of an existing name. Punctuation need not reflect the usage of the original. Subtitles should be separated from the title by a sequence of space-colon-space, for example: Voices from the Dust Bowl: The Charles L. Todd and Robert Sonkin Migrant Worker Collection “
DCMI specs for Application Profiles Singapore Framework http://dublincore.org/documents/singapore-framework/ Documentation guidelines, January 2008 Description Set Profiles http://dublincore.org/documents/dc-dsp/ Formal (machine-readable) part of Singapore Framework Working draft, March 2008 Implementation expercience still needed
Summary Dublin Core metadata defined by different forms of “interoperability” For human understanding Machine semantics Metadata records Application Profiles Projects need to place themselves on this map What do I need? How can I achieve it? The Dublin Core community is open to implementers at all levels
Dublin Core and other metadata schemas Mikael Nilsson < [email_address] >
Interoperability Levels for Dublin Core metadata Level 1: Informal interoperability Shared concepts with natural-language definitions No use of formal models or term URIs Test: Is there a mapping to shared elements? Example: IEEE LOM reuses some definitions and maps to 15-element “Dublin Core” (ISO 15836)
Interoperability Levels for Dublin Core metadata Level 2: Semantic Interoperability Correct use of formal RDF graph model with conformant vocabularies (eg DCMI Metadata terms) Use of URIs and formal semantic relationships between terms (eg subproperties) Test: Is there a mapping to RDF triples? Examples: All RDF data (by definition) All RDF data extracted from non-RDF formats (eg via GRDDL transforms) All XHTML or HTML data using RDFa or DC-HTML/2008.
Interoperability Levels for Dublin Core metadata Level 3: Description set syntactic interoperability Level-2-compatible data packaged in bounded description sets (records) as per DCMI Abstract Model (DC-AM) Conventions for citing vocabulary encoding schemes (controlled vocabularies) Test: Is there a mapping to “Expressing Dublin Core metadata using the DC-Text format”? Examples: All data using DC-AM-compatible specifications, such as DC-DS-XML.
Interoperability Levels for Dublin Core metadata Level 4: Description Set Profile Interoperability Level-3-compatible data that follows the specification “Description Set Profiles: A constraint language for Dublin Core Application Profiles” Additional interoperability via shared Functional Requirements and Domain Model (“Singapore Framework for Dublin Core Application Profiles”) Test: Is there a mapping to DSP constraints? Examples: Scholarly Works Application Profile
Interoperability Levels for Dublin Core metadata Level 4: Description Set Profile Interoperability Level 3: Description Set syntactic interoperability Level 2: Semantic interoperability Level 1: Informal interoperability

More Related Content

ODP
ISO MLR semantics
Mikael Nilsson
 
PPT
DC Architecture WG Meeting - DC-2006, Mexico
Eduserv Foundation
 
PPT
Dublin Core In Practice
Marcia Zeng
 
PPT
Everything you wanted to know about Dublin Core metadata
Eduserv Foundation
 
PPT
Rdf And Rdf Schema For Ontology Specification
chenjennan
 
PPT
Linked Data Driven Data Virtualization for Web-scale Integration
rumito
 
PPT
Report on Work of Joint DCMI/IEEE LTSC Task Force
Eduserv Foundation
 
ODP
DC-2008 DCMI/IEEE workshop
Mikael Nilsson
 
ISO MLR semantics
Mikael Nilsson
 
DC Architecture WG Meeting - DC-2006, Mexico
Eduserv Foundation
 
Dublin Core In Practice
Marcia Zeng
 
Everything you wanted to know about Dublin Core metadata
Eduserv Foundation
 
Rdf And Rdf Schema For Ontology Specification
chenjennan
 
Linked Data Driven Data Virtualization for Web-scale Integration
rumito
 
Report on Work of Joint DCMI/IEEE LTSC Task Force
Eduserv Foundation
 
DC-2008 DCMI/IEEE workshop
Mikael Nilsson
 

What's hot (20)

PPT
Linked Data Planet Key Note
rumito
 
ODP
LOM DCAM at LOM Meeting 2008-04-23
Mikael Nilsson
 
PPT
Dublin Core Metadata Initiative Abstract Model
Jenn Riley
 
PPT
Deploying RDF Linked Data via Virtuoso Universal Server
rumito
 
PPT
Metadata Cloud
Norm Friesen
 
PDF
semanticweb
Kevin Hutt
 
PPTX
Introduction to RDA
Bhgn. Pembangunan Bibliografik & Pemprosesan Teknikal
 
PPT
Alphabet Soup: Choosing Among DC, QDC, MARC, MARCXML, and MODS
Jenn Riley
 
PPT
DCMI Abstract Model: issues and proposed changes
Eduserv Foundation
 
PPTX
Xml applications
Nabahat Tahir
 
PDF
XML and XML Applications - Lecture 04 - Web Information Systems (WE-DINF-11912)
Beat Signer
 
PPTX
Web data management
Abdul Hannan
 
PPT
Swap For Dummies Rsp 2007 11 29
Julie Allinson
 
PPTX
Web data management (chapter-1)
Dhaval Asodariya
 
ODP
Description Set profiles
Mikael Nilsson
 
PPT
Genre discovery in corpus management systems (2004)
Joseba Abaitua
 
PPT
DC-Text: a simple text-based format for DC metadata
Eduserv Foundation
 
PPTX
Owl web ontology language
hassco2011
 
PDF
Spotlight
Stefano Lariccia
 
PDF
Matching and merging anonymous terms from web sources
IJwest
 
Linked Data Planet Key Note
rumito
 
LOM DCAM at LOM Meeting 2008-04-23
Mikael Nilsson
 
Dublin Core Metadata Initiative Abstract Model
Jenn Riley
 
Deploying RDF Linked Data via Virtuoso Universal Server
rumito
 
Metadata Cloud
Norm Friesen
 
semanticweb
Kevin Hutt
 
Introduction to RDA
Bhgn. Pembangunan Bibliografik & Pemprosesan Teknikal
 
Alphabet Soup: Choosing Among DC, QDC, MARC, MARCXML, and MODS
Jenn Riley
 
DCMI Abstract Model: issues and proposed changes
Eduserv Foundation
 
Xml applications
Nabahat Tahir
 
XML and XML Applications - Lecture 04 - Web Information Systems (WE-DINF-11912)
Beat Signer
 
Web data management
Abdul Hannan
 
Swap For Dummies Rsp 2007 11 29
Julie Allinson
 
Web data management (chapter-1)
Dhaval Asodariya
 
Description Set profiles
Mikael Nilsson
 
Genre discovery in corpus management systems (2004)
Joseba Abaitua
 
DC-Text: a simple text-based format for DC metadata
Eduserv Foundation
 
Owl web ontology language
hassco2011
 
Spotlight
Stefano Lariccia
 
Matching and merging anonymous terms from web sources
IJwest
 
Ad

Similar to DC-2008 Architecture Forum Open session (20)

ODP
RDA-DCAM and Application Profiles
Mikael Nilsson
 
PPT
Dublin Core, the DCMI Abstract Model & DC Application Profiles
Eduserv Foundation
 
PPT
The JISC DC Application Profiles: Some thoughts on requirements and scope
Eduserv Foundation
 
PPT
Dublin Core Description Set Profiles (DC-2009)
Pete Johnston
 
PPTX
Flexible metadata schemes for research data repositories - Clarin Conference...
Vyacheslav Tykhonov
 
PPTX
Flexible metadata schemes for research data repositories - CLARIN Conference'21
vty
 
ODP
DCMI IEEE LTSC Joint taskforce at DC2007
Mikael Nilsson
 
ODP
DC-2008 Tutorial 3 - Dublin Core and other metadata schemas
Mikael Nilsson
 
PDF
Building social and RESTful frameworks
brendonschwartz
 
PPT
Dublin Core Description Set Profiles
Pete Johnston
 
PPTX
How to describe a dataset. Interoperability issues
Valeria Pesce
 
PPTX
How to Describe a Dataset. Interoperability Issues, by Valeria Pesce
AIMS (Agricultural Information Management Standards)
 
PPTX
Expressing Concept Schemes & Competency Frameworks in CTDL
Credential Engine
 
PPT
Understanding RDF: the Resource Description Framework in Context (1999)
Dan Brickley
 
PPT
Chapter02
sasa_eldoby
 
PPTX
Atla dublin core basics workshop
Lisa Gonzalez
 
PPT
Database Systems Concepts, 5th Ed
Daniel Francisco Tamayo
 
PPT
DC-2008 Tutorial: Basic Concepts
Eduserv Foundation
 
PPTX
Database Languages Architecture Data Model.pptx
shahid1204as
 
PPT
Introduction to Oracle
Achmad Solichin
 
RDA-DCAM and Application Profiles
Mikael Nilsson
 
Dublin Core, the DCMI Abstract Model & DC Application Profiles
Eduserv Foundation
 
The JISC DC Application Profiles: Some thoughts on requirements and scope
Eduserv Foundation
 
Dublin Core Description Set Profiles (DC-2009)
Pete Johnston
 
Flexible metadata schemes for research data repositories - Clarin Conference...
Vyacheslav Tykhonov
 
Flexible metadata schemes for research data repositories - CLARIN Conference'21
vty
 
DCMI IEEE LTSC Joint taskforce at DC2007
Mikael Nilsson
 
DC-2008 Tutorial 3 - Dublin Core and other metadata schemas
Mikael Nilsson
 
Building social and RESTful frameworks
brendonschwartz
 
Dublin Core Description Set Profiles
Pete Johnston
 
How to describe a dataset. Interoperability issues
Valeria Pesce
 
How to Describe a Dataset. Interoperability Issues, by Valeria Pesce
AIMS (Agricultural Information Management Standards)
 
Expressing Concept Schemes & Competency Frameworks in CTDL
Credential Engine
 
Understanding RDF: the Resource Description Framework in Context (1999)
Dan Brickley
 
Chapter02
sasa_eldoby
 
Atla dublin core basics workshop
Lisa Gonzalez
 
Database Systems Concepts, 5th Ed
Daniel Francisco Tamayo
 
DC-2008 Tutorial: Basic Concepts
Eduserv Foundation
 
Database Languages Architecture Data Model.pptx
shahid1204as
 
Introduction to Oracle
Achmad Solichin
 
Ad

More from Mikael Nilsson (11)

ODP
DC-2008 Identifiers presentation
Mikael Nilsson
 
PPT
DCMI/IEEE workshop DC2005
Mikael Nilsson
 
ODP
Matriks KTHB Temadag
Mikael Nilsson
 
ODP
Matriks Workshop
Mikael Nilsson
 
ODP
Matriks-presentation för BIBSAM
Mikael Nilsson
 
ODP
DC Architecture at DC2007
Mikael Nilsson
 
ODP
JISC CETIS Semantic Technologies 2007-11-21
Mikael Nilsson
 
PPT
Chicago LOMRDF update 2003-06-19
Mikael Nilsson
 
PPT
Leuven Ariadne LOMRDF 2003 11 20
Mikael Nilsson
 
PPT
PADRL Presentation 2001-11-03
Mikael Nilsson
 
PPT
CID presentation för VINNOVA 2003-03-28
Mikael Nilsson
 
DC-2008 Identifiers presentation
Mikael Nilsson
 
DCMI/IEEE workshop DC2005
Mikael Nilsson
 
Matriks KTHB Temadag
Mikael Nilsson
 
Matriks Workshop
Mikael Nilsson
 
Matriks-presentation för BIBSAM
Mikael Nilsson
 
DC Architecture at DC2007
Mikael Nilsson
 
JISC CETIS Semantic Technologies 2007-11-21
Mikael Nilsson
 
Chicago LOMRDF update 2003-06-19
Mikael Nilsson
 
Leuven Ariadne LOMRDF 2003 11 20
Mikael Nilsson
 
PADRL Presentation 2001-11-03
Mikael Nilsson
 
CID presentation för VINNOVA 2003-03-28
Mikael Nilsson
 

Recently uploaded (20)

PPTX
Pharma ospi slides which help in ospi learning
rameetkumar304
 
PPTX
school management -TNTEU- B.Ed., Semester II Unit 1.pptx
NihumathunnisaH
 
PDF
O5-L3 Freight Transport Ops (International) V1.pdf
labyankof
 
PDF
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
HakHe
 
PDF
2.FourierTransform-ShortQuestionswithAnswers.pdf
Raji Murugan
 
PPTX
Introduction_to_Human_Anatomy_and_Physiology_for_B.Pharm.pptx
chetansingh379583
 
PDF
Abdominal Access Techniques with Prof. Dr. R K Mishra
mohitsuren827
 
PPTX
GDM (1) (1).pptx small presentation for students
shrawanbpkihs
 
PPTX
IMMUNITY IMMUNITY refers to protection against infection, and the immune syst...
shilpa939953
 
PDF
grade 11-chemistry_fetena_net_5883.pdf teacher guide for all student
banteamlakmebratu738
 
PPTX
Final Presentation General Medicine 03-08-2024.pptx
ZaheerAhmad228692
 
PDF
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
MarjorieLopezTiu
 
PDF
Supply Chain Operations Speaking Notes -ICLT Program
labyankof
 
PPTX
Lesson notes of climatology university.
sgladness67
 
PDF
TR - Agricultural Crops Production NC III.pdf
avgilmegino3
 
PDF
102 student loan defaulters named and shamed – Is someone you know on the list?
Kweku Zurek
 
PDF
Pre independence Education in Inndia.pdf
goofy5603
 
PDF
VCE English Exam - Section C Student Revision Booklet
jpinnuck
 
PDF
Microbial disease of the cardiovascular and lymphatic systems
KeyaSharma
 
PPTX
Pharmacology of Heart Failure /Pharmacotherapy of CHF
Rajshri Ghogare
 
Pharma ospi slides which help in ospi learning
rameetkumar304
 
school management -TNTEU- B.Ed., Semester II Unit 1.pptx
NihumathunnisaH
 
O5-L3 Freight Transport Ops (International) V1.pdf
labyankof
 
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
HakHe
 
2.FourierTransform-ShortQuestionswithAnswers.pdf
Raji Murugan
 
Introduction_to_Human_Anatomy_and_Physiology_for_B.Pharm.pptx
chetansingh379583
 
Abdominal Access Techniques with Prof. Dr. R K Mishra
mohitsuren827
 
GDM (1) (1).pptx small presentation for students
shrawanbpkihs
 
IMMUNITY IMMUNITY refers to protection against infection, and the immune syst...
shilpa939953
 
grade 11-chemistry_fetena_net_5883.pdf teacher guide for all student
banteamlakmebratu738
 
Final Presentation General Medicine 03-08-2024.pptx
ZaheerAhmad228692
 
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
MarjorieLopezTiu
 
Supply Chain Operations Speaking Notes -ICLT Program
labyankof
 
Lesson notes of climatology university.
sgladness67
 
TR - Agricultural Crops Production NC III.pdf
avgilmegino3
 
102 student loan defaulters named and shamed – Is someone you know on the list?
Kweku Zurek
 
Pre independence Education in Inndia.pdf
goofy5603
 
VCE English Exam - Section C Student Revision Booklet
jpinnuck
 
Microbial disease of the cardiovascular and lymphatic systems
KeyaSharma
 
Pharmacology of Heart Failure /Pharmacotherapy of CHF
Rajshri Ghogare
 

DC-2008 Architecture Forum Open session

  • 1. Architecture Forum Open session Mikael Nilsson < [email_address] >
  • 2. Major goals of the Architecture Forum Document the DCMI metadata framework Develop technical specifications Provide feedback on technical issues To DCMI users To other DCMI communities To the Usage Board Serve as a platform for discussions and evaluations of future technical directions
  • 3. Major specifications from DC-ARCH DCMI Abstract Model (2005, 2007) Underlying model for DCMI metadata Defines notions of Property Vocabulary Encoding Scheme Syntax Encoding Scheme Etc ... and how they fit together Used as basis for metadata expressions Used as basis for how DCMI terms are defined
  • 4. Understanding the model Literal and non-literal values “ Description sets” vs “records” “ Values” vs “value strings” and URIs “ Domain model” of described entities
  • 5. Who needs to understand what? Application architects (who implement) To follow model, need to know all of the above! Understand how formats express the model Non-expert users (who define requirements) Examples of common design patterns Simple question trees for narrowing choices Palette of pre-defined well-engineered choices
  • 6. Guidelines for profile designers Guidelines for Dublin Core Application Profiles Palette of profile snippets to cut-and-paste? Wiki format convertible into XML Library of usage templates?
  • 7. Major specifications from DC-ARCH DCMI Metadata expressions DC-RDF (2008) Replaces DCQ-RDF-XML (2002) and DCMES-XML (2002) DC-HTML (2008) Replaces DCQ-HTML (2003) DC-DS-XML (200?) Might replace DC-XML (2003) DC-TEXT (2007) A simple human-readable text format (not for machine processing)
  • 8. Major specifications from DC-ARCH Singapore Framework for DC Application Profiles (2008) Description set profiles (200?) - working draft Interoperability levels for Dublin Core metadata
  • 9. The Singapore Framework In Singapore, at DC2007, a new definition of a “Dublin Core Application Profile” was introduced A “DC Application Profile” is packet of documentation which consists of: Functional requirements (mandatory) Domain model (mandatory) Description Set Profile (DSP) (mandatory) Usage guidelines (optional) Encoding syntax guidelines (optional)
  • 10. Profiles and standards Profiles are based on domain standards: Standard metadata vocabularies (e.g., Dublin Core elements) Standard domain models (e.g., FRBR) Functional Requirements for Bibliographic Records A standard record model (DCMI Abstract Model) Foundation is Resource Description Framework (“Semantic Web”) RDF is the model underlying the DCMI Abstract Model RDF Schema is the model underlying the machine processable definitions of terms
  • 12. The Singapore Framework Foundation standards Domain standards Application Profile
  • 13. Interoperability Levels for Dublin Core metadata Level 1: Informal interoperability Shared concepts with natural-language definitions No use of formal models or term URIs Test: Is there a mapping to shared elements? Example: IEEE LOM reuses some definitions and maps to 15-element “Dublin Core” (ISO 15836)
  • 14. Interoperability Levels for Dublin Core metadata Level 2: Semantic Interoperability Correct use of formal RDF graph model with conformant vocabularies (eg DCMI Metadata terms) Use of URIs and formal semantic relationships between terms (eg subproperties) Test: Is there a mapping to RDF triples? Examples: All RDF data (by definition) All RDF data extracted from non-RDF formats (eg via GRDDL transforms) All XHTML or HTML data using RDFa or DC-HTML/2008.
  • 15. Interoperability Levels for Dublin Core metadata Level 3: Description set syntactic interoperability Level-2-compatible data packaged in bounded description sets (records) as per DCMI Abstract Model (DC-AM) Conventions for citing vocabulary encoding schemes (controlled vocabularies) Test: Is there a mapping to “Expressing Dublin Core metadata using the DC-Text format”? Examples: All data using DC-AM-compatible specifications, such as DC-DS-XML.
  • 16. Interoperability Levels for Dublin Core metadata Level 4: Description Set Profile Interoperability Level-3-compatible data that follows the specification “Description Set Profiles: A constraint language for Dublin Core Application Profiles” Additional interoperability via shared Functional Requirements and Domain Model (“Singapore Framework for Dublin Core Application Profiles”) Test: Is there a mapping to DSP constraints? Examples: Scholarly Works Application Profile
  • 17. Interoperability Levels for Dublin Core metadata Level 4: Description Set Profile Interoperability Level 3: Description Set syntactic interoperability Level 2: Semantic interoperability Level 1: Informal interoperability
  • 18. Mikael Nilsson < [email_address] > DC 2007, Singapore Aug 27-31, 2007 Description Set Profiles
  • 19. DC Application Profiles - traditional definition “ A Dublin Core Application Profile (DCAP) is a declaration specifying which metadata terms an organization, information provider, or user community uses in its metadata. By definition, a DCAP identifies the source of metadata terms used—whether they have been defined in formally maintained standards such as Dublin Core, in less formally defined element sets and vocabularies, or by the creator of the DCAP itself for local use in an application. Optionally, a DCAP may provide additional documentation on how the terms are constrained, encoded or interpreted for application-specific purposes.” -- CEN CWA 14855:2003
  • 20. Machine-readable constraints? XML Schema? Not applicable to RDF Not applicable to HTML Not applicable to .... CEN Guidelines Not based on DCAM No support for Description Sets Needed something new “ Dublin Core Description Set Profile”
  • 21. Envisioned usages as a formal representation of the constraints of a Dublin Core Application Profile as configuration for databases as configuration for metadata editing tools etc.
  • 22. Scope of a DSP spec Information model: Structural constraints on a description set: what descriptions may occur what properties may be used what ways might a value surrogate be given XML expression
  • 23. Out of scope Human-readable documentation Definition of vocabularies Version control etc.
  • 24. DC Application Profiles - new definition (in progress) A DCAM-conformant Application Profile (“DC Application Profile”) is packet of documentation which consists of: Functional requirements (mandatory) Domain model (mandatory) Description Set Profile (DSP) (mandatory) Usage guidelines (optional) Encoding syntax guidelines (optional)
  • 25.  
  • 26. Foundation standards Domain standards Application Profile
  • 27. First working draft http://dublincore.org/architecturewiki/DescriptionSetProfile Comments on DC-ARCHITECTURE Publication schedule not defined
  • 28. Example: The book AP A book: a literal title a creator, described separately A creator a literal name
  • 29. Statement template: literal title dcterms:title Literal value Language SES Property: Statement template: creator dcterms:creator Value string Language SES Property: Value URI Vocabulary Encoding Scheme Description reference: Creator Statement template: literal name foaf:name Literal value Language SES Property: standalone:no Description Template: Book Description Template: Creator
  • 30. {{{#!DSP == Description template: Book == DT=(min=&quot;1&quot; max=&quot;1&quot; standalone=&quot;yes&quot; identifier=&quot;book&quot;) === Title === ST=(max=&quot;1&quot; type=&quot;literal&quot; PC={http://purl.org/dc/terms/title}) || Definition || A name given to the resource. || LC=(LangC=(occurrence=&quot;optional&quot;) SESConstraint=(occurrence=&quot;disallowed&quot;) ) === Creator === ST=(max=&quot;1&quot; type=&quot;nonliteral&quot; PC={http://purl.org/dc/terms/creator}) || Definition || An entity primarily responsible for making the resource. || NLC=(VURIConstraint=(occurrence=&quot;disallowed&quot;) VESConstraint=(occurrence=&quot;disallowed&quot;) VStringConstraint=(max=&quot;1&quot; LangC=(occurrence=&quot;disallowed&quot;) SESConstraint=(occurrence=&quot;disallowed&quot;)) description=&quot;creator&quot; ) == Description template: Creator == DT=(min=&quot;1&quot; max=&quot;1&quot; standalone=&quot;no&quot; identifier=&quot;creator&quot;) === Name === ST=(max=&quot;1&quot; type=&quot;literal&quot; PC={http://xmlns.com/foaf/0.1/name}) || Definition || A name for some thing. || LC=(LangC=(occurrence=&quot;disallowed&quot;) SESConstraint=(occurrence=&quot;disallowed&quot;) ) }}} http://knowware.nada.kth.se/DCWiki/TheBookAP?action=raw http://knowware.nada.kth.se/DCWiki/TheBookAP http://knowware.nada.kth.se/DCWiki/TheBookAP?action=DSP2XML Link
  • 32. <?xml version=&quot;1.0&quot;?> <DescriptionSetTemplate> <DescriptionTemplate maxOccur=&quot;1&quot; minOccur=&quot;1&quot;> <StatementTemplate maxOccur=&quot;1&quot; type=&quot;literal&quot;> <Property>http://purl.org/dc/terms/title</Property> <LiteralConstraint> <SyntaxEncodingSchemeOccurrence>disallowed</SyntaxEncodingSchemeOccurrence> <LanguageOccurrence>optional</LanguageOccurrence> </LiteralConstraint> </StatementTemplate> <StatementTemplate maxOccur=&quot;1&quot; type=&quot;nonliteral&quot;> <Property>http://purl.org/dc/terms/creator</Property> <NonliteralConstraint descriptionTemplateID=&quot;creator&quot;> <ValueURIOccurrence>disallowed</ValueURIOccurrence> <VocabularyEncodingSchemeOccurrence>disallowed</VocabularyEncodingSchemeOccurrence> <ValueStringConstraint maxOccur=&quot;1&quot;> <SyntaxEncodingSchemeOccurrence>disallowed</SyntaxEncodingSchemeOccurrence> <LanguageOccurrence>disallowed</LanguageOccurrence> </ValueStringConstraint> </NonliteralConstraint> </StatementTemplate> </DescriptionTemplate> <DescriptionTemplate maxOccur=&quot;1&quot; minOccur=&quot;1&quot;> <StatementTemplate maxOccur=&quot;1&quot; type=&quot;literal&quot;> <Property>http://xmlns.com/foaf/0.1/name</Property> <LiteralConstraint> <SyntaxEncodingSchemeOccurrence>disallowed</SyntaxEncodingSchemeOccurrence> <LanguageOccurrence>disallowed</LanguageOccurrence> </LiteralConstraint> </StatementTemplate> </DescriptionTemplate> </DescriptionSetTemplate> http://knowware.nada.kth.se/DCWiki/TheBookAP?action=raw http://knowware.nada.kth.se/DCWiki/TheBookAP http://knowware.nada.kth.se/DCWiki/TheBookAP?action=DSP2XML
  • 33. Putting DSPs to work The SHAME demo Takes DSP-XML Generates an RDF editor on the fly RDF conforms to DSP constraints
  • 34. The speaker PhD student at Royal Inst. of Technology, Stockholm Subject: Metadata Standardization and Interoperability Engaged in metadata within IEEE, ISO, DCMI Co-chair of DC Architecture Forum Joint DCMI / IEEE LTSC Taskforce Co-author of DCMI Abstract Model Expressing Dublin Core in RDF Singapore Framework for DC Application Profiles
  • 35. Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
  • 36. Metadata specifications outside of DCMI Many domains: E-Government Education Geospatial information Libraries Business Multimedia Geospatial information etc.
  • 37. Metadata specifications outside of DCMI Many technical environments Low-level (file systems, protocols etc) File formats (HTML, Atom, etc.) Ontologies (OWL, etc.) Repositories Harvesting
  • 38. Metadata specifications outside of DCMI Many expressions XML RDF SQL HTML ID3 EXIF
  • 39. Metadata specifications outside of DCMI Many complete “schemas” MARC METS MODS IEEE LOM MPEG-7 CSDGM etc.
  • 40. Metadata specifications outside of DCMI Many purposes Search Describe Administrate Structure etc.
  • 41. “Interoperable with Dublin Core”? What does it take to be called interoperable? Specific domain? NO Specific technical environment? NO Specific expression? NO Specific complete “schema”? Not really... Specific purpose? NO But seriously...? ...we obviosly need to talk about the term “ interoperability”
  • 42. Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
  • 43. The elusive notion of interoperability IEEE definition of interoperability: “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.” DCMI has four notions of “use the information”: Use the documented definition of the DCMI terms Use the machine-processable semantics of terms Use the structure of the metadata record Use the constraints in an application profile Each usage leads to a different notion of interoperability
  • 44. DCMI specifications for interoperability Textual definition of the DCMI terms: DCMI Metadata Terms Machine-processable semantics of terms: DCMI Abstract Model RDF expression of Dublin Core metadata RDF schemas for DCMI terms Metadata records DCMI Abstract Model - “description sets” DCMI expressions: XML, (X)HTML, etc. Application profiles Singapore Framework Description Set Profiles
  • 45. Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
  • 46. Human semantics for Dublin Core The Dublin Core terms have carefully crafted definitions Example: Label: Creator Definition: An entity primarily responsible for making the resource. Comment: Examples of a Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity. The meaning of these terms is well understood Therefore, we often see compatible definitions used in other specifications The 15 elements in the “Dublin Core Metadata Element Set” are most often reused
  • 47. Example: IEEE LOM IEEE LOM is the major metadata specification used for Learning resources 1.6 Coverage The time, culture, geography or region to which this learning object applies. The extent or scope of the content of the learning object. Coverage will typically include spatial location [...] NOTE —This is the definition from the Dublin Core Metadata Element Set, version 1.1
  • 48. Example: The Atom Syndication Format Atom (like RSS) is used for content syndication (news feeds, podcasts etc.) The &quot;atom:rights&quot; element is a Text construct that conveys information about rights held in and over an entry or feed. (RFC 4287) Cf. the Dublin Core term “Rights”: “Information about rights held in and over the resource.”
  • 49. Uses of human semantics Compatible reuse of Dublin Core element semantics implies: Well-understood definitions Easier to input metadata Easier to process metadata Definitions interoperable with other metadata specifications Less work to design a metadata specification Easier to create crosswalks Etc. Human semantics often sufficient for limited locally scoped projects
  • 50. Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
  • 51. Dublin Core in the wild: The Semantic Web The DCMI Terms carry machine-readable definitions as well: <rdf:Description rdf:about=&quot; http://purl.org/dc/terms/creator &quot;> <rdfs: label xml:lang=&quot;en-US&quot; > Creator </rdfs:label> <rdfs: comment xml:lang=&quot;en-US&quot; > An entity primarily responsible for making the resource. </rdfs:comment> <dcterms: description xml:lang=&quot;en-US&quot; > Examples of a Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity. </dcterms:description> <rdfs: isDefinedBy rdf:resource=&quot; http://purl.org/dc/terms/ &quot;/> <dcterms: issued > 2008-01-14 </dcterms:issued> <dcterms: modified > 2008-01-14 </dcterms:modified> <rdf: type rdf:resource=&quot; http://www.w3.org/1999/02/22-rdf-syntax-ns#Property &quot;/> <dcterms :hasVersion rdf:resource=&quot; http://dublincore.org/usage/terms/history/#creatorT-001 &quot;/> <rdfs: range rdf:resource=&quot; http://purl.org/dc/terms/Agent &quot;/> <rdfs: subPropertyOf rdf:resource=&quot; http://purl.org/dc/elements/1.1/creator &quot;/> <rdfs: subPropertyOf rdf:resource=&quot; http://purl.org/dc/terms/contributor &quot;/> </rdf:Description>
  • 52. Terms are referenced by URI Unique identification part of the framework The meaning of terms is carried by the URI No need for manual crosswalks “Context-free” metadata Metadata can be merged, mixed and matched No trouble combining metadata from several sources Usage of terms is restricted by domains and ranges A “Creator” of a resource is always an Agent. Improves processing possibilities “Refinements” are part of the framework A “Vocalist” (marcrel:VOC) of a resource is understood to be “Contributor” (dc:contributor) of the same resource. What happens on the Semantic Web?
  • 53. Example: Adobe XMP Metadata part of media files (JPEG, PDF, RAW, etc.) Supported in a wide range of Adobe products Mixes Dublin Core properties with EXIF properties PDF properties Etc. < dc:publisher > <rdf:Bag> <rdf:li rdf:parseType=&quot;Resource&quot;> <rdf:value>James Bond</rdf:value> <ns:role>secret agent</ns:role> </rdf:li> </rdf:Bag> </dc:publisher> < tiff:ImageDescription > <rdf:Alt> <rdf:li xml:lang=&quot;x-default&quot;>TIFF image description</rdf:li> <rdf:li xml:lang=&quot;de-DE&quot;>TIFF Bildbeschreibung</rdf:li> </rdf:Alt> </tiff:ImageDescription> < xmpDM:videoFrameSize stDim:w=&quot;16&quot; stDim:h=&quot;9&quot; stDim:unit=&quot;inch&quot;/>
  • 54. Example: Open Document Format ODF 1.2 (OASIS) introduced RDF-based metadata Supports metadata in Manifest (metadata file) Inline in text of document < bibtex:Article rdf:about=&quot;info:pmid/17445913&quot;> < dc:title >Neuraminidase inhibitor susceptibility[...].</dc:title> < dcterms:abstract >As an intermediate host of avian and [...] .</dcterms:abstract> < dc:creator >K Bauer</dc:creator> <dc:creator>M Schmidtke</dc:creator> < foaf:maker > < foaf:Person rdf:about=&quot;http://purl.org/net/hubmed/ns/pmids/17445913/authors/Bauer,K&quot;> < foaf:name >K Bauer</foaf:name> <rdf:value>K Bauer</rdf:value> <foaf:givenname></foaf:givenname> <foaf:surname>Bauer</foaf:surname> </foaf:Person> </foaf:maker> < dc:identifier >10.1016/j.antiviral.2007.03.007</dc:identifier> < prism:publicationName >Antiviral Res</prism:publicationName> <prism:publicationDate>2007-09</prism:publicationDate> <prism:volume>75</prism:volume> <prism:number>3</prism:number> <prism:startingPage>219</prism:startingPage> <prism:endingPage>226</prism:endingPage> <prism:isPartOf rdf:resource=&quot;urn:issn:0166-3542&quot;/> </bibtex:Article>
  • 55. Uses of machine semantics The use of a common framework means metadata... from different domains using different vocabularies used in different technical environments... ... can be combined without effort. Ontologies Enable advanced processing of metadata Automatic discovery of term definitions “Follow your nose” Linked open data Giant global graph of metadata
  • 56. Follow your nose http://xmlns.com/foaf/0.1/knows RDF Schema label comment range HTML http://example.com/persons#john http://example.com/persons#gordon FOAF specification http://xmlns.com/foaf/0.1/knows “ Knows” “ A person known by this person (indicating some level of reciprocated interaction between the parties)” foaf:Person
  • 57. Linked Open Data More than 2 billion RDF triples
  • 58. Support for machine semantics in DCMI DCMI Abstract Model Lays the foundations for definition and usage of terms in Dublin Core metadata Builds on RDF RDF schemas for DCMI terms Available in “follow your nose”-compatible way RDF expression of Dublin Core Defines how to express Dublin Core metadata using RDF
  • 59. Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
  • 60. Metadata records: structure in the chaos Dublin Core builds on experiences from the library community A strong influence is the “library card” A managable “unit of metadata” On the other hand: the “one-to-one principle” One resource, one description A Book and its author are described separately A Book and a digital copy are described separately The DCMI Abstract Model A formalization of the “library card” for Dublin Core, first formalized in 2005
  • 61. Why the DCMI Abstract Model? A DCMI-specific definition of “metadata record” A framework for designing metadata records A basis for validation of records A basis for exchange formats for records The DCAM provides A notion of a “description set”( = record) as a collection of descriptions of individual resources. A formalization of earlier practices in the DC community
  • 62. Example: DC-DS-XML A proposed XML language that provides a generic XML encoding for DC metadata Allows for validation with XML schema Any properties (even non-DC) can be used. <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; ?> <dcds: descriptionSet xmlns:dcds=&quot;http://purl.org/dc/xmlns/2008/09/01/dc-ds-xml/&quot;> <dcds: description dcds: resourceURI =&quot;http://dublincore.org/pages/home&quot;> <dcds:statement dcds:propertyURI=&quot;http://purl.org/dc/terms/title&quot; > <dcds: literalValueString xml:lang=&quot;en-GB&quot;> DCMI Home Page </dcds:literalValueString> </dcds:statement> <dcds:statement dcds:propertyURI=&quot;http://purl.org/dc/terms/publisher&quot; dcds: valueURI=&quot;http://example.org/agents/DCMI&quot; > <dcds:valueString>Dublin Core Metadata Initiative</dcds:valueString> </dcds:statement> <dcds:statement dcds: propertyURI=&quot;http://purl.org/dc/terms/date&quot; > <dcds: literalValueString > 2005-05-05 </dcds:literalValueString> </dcds:statement> </dcds:description> </dcds:descriptionSet>
  • 63. Example: DC-HTML HTML encoding of metadata records Does not support full version of DCAM Any properties (even non-DC) can be used. <?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?> <!DOCTYPE html PUBLIC &quot;-//W3C//DTD XHTML 1.0 Strict//EN&quot; &quot;http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd&quot;> <html xmlns=&quot;http://www.w3.org/1999/xhtml&quot;> <head profile=&quot;http://dublincore.org/documents/2008/08/04/dc-html/&quot;> <title>Services to Government</title> <link rel=&quot;schema.DC&quot; href=&quot;http://purl.org/dc/elements/1.1/&quot; /> <link rel=&quot;schema.MARCREL&quot; href=&quot;http://www.loc.gov/loc.terms/relators/&quot; /> <meta name=&quot; DC.title &quot; content=&quot; Services to Government &quot; /> <link rel=&quot; MARCREL.EDT &quot; href=&quot; http://example.org/agents/DeptOfObfuscation &quot; /> </head>
  • 64. Connecting records and semantics Newer DCMI syntaxes support GRRDL from W3C “Gleaning Resource Descriptions from Dialects of Languages” Idea: All XML-based languages can auto-generate RDF data For DCAM-based formats, it's straightforward. Other XML languages are starting to use GRDDL In particular, the Microformats community
  • 65. Example: From XML to graphs <LearningResource grddl:transform=”http://yyy/mlr.xsl” > <Title>A book</title> <Contribution> <Date>2008-09-03</Date> <Entity> <Name>John Smith</Name> </Entity> </Contribution> </LearningResource> http://yyy/mlr.xsl foaf:name foaf:mbox foaf:knows title contribution date entity name foaf:mbox foaf:knows http://example.com/persons#john “ John Smith” “ [email_address] ” http://example.com/persons#gordon My learning resource Contribution A http://example.com/persons#john “ A book” “ John Smith” “ 2008-09-03” “ [email_address] ” http://example.com/persons#gordon My learning resource Contribution A Person B “ A book” “ John Smith” “ 2008-09-03” title contribution date entity name
  • 66. Metadata islands... IEEE LOM NorLOM UK LOM Core ... RDF Dublin Core DC APs Semantic Web ... MARC21 MARC-XML METS METS MPEG-7
  • 67. ... and a metadata interoperability vision Education Government Libraries Multimedia Semantic Web
  • 68. Metadata records in DCMI specifications DCMI Abstract Model Defines “description sets”, the DCMI notion of metadata records DC-DS-XML Encodes general description sets in XML DC-HTML? Supports a single description in HTML/XHTML With a few limitations DC-RDF? Does not represent “records” explicitly
  • 69. Overview of tutorial Metadata specifications Interoperability The human side of metadata The Semantic web Metadata records Application Profiles
  • 70. Dublin Core Application Profiles We have a definition of managable records We have the option of global interoperability We have the widely used term definitions What's left? Community interoperability! A particular application, domain or community may want Better documentation of their metadata records More support for quality control / validation This is usually described with Application Profiles
  • 71. Application Profiles Specifies a community's use of metadata records Defines What things are described? Why? Which properties are used? What kinds of values are used? What vocabularies are referenced? What guidelines for data entry are used? etc.
  • 72. A word of Warning DCMI uses “application profile” to mean: A specification of which metadata terms are used A specification of how those terms are constrained and interpreted in the local context Other communities use “profile” to mean A customization of an existing schema Starts from a “base” standard, adds context-specifics The two notions are not very interoperable!
  • 73. The Singapore Framework In Singapore, at DC2007, a new definition of a “Dublin Core Application Profile” was introduced A “DC Application Profile” is packet of documentation which consists of: Functional requirements (mandatory) Domain model (mandatory) Description Set Profile (DSP) (mandatory) Usage guidelines (optional) Encoding syntax guidelines (optional)
  • 74. Profiles and standards Profiles are based on domain standards: Standard metadata vocabularies (e.g., Dublin Core elements) Standard domain models (e.g., FRBR) Functional Requirements for Bibliographic Records A standard record model (DCMI Abstract Model) Foundation is Resource Description Framework (“Semantic Web”) RDF is the model underlying the DCMI Abstract Model RDF Schema is the model underlying the machine processable definitions of terms
  • 76. The Singapore Framework Foundation standards Domain standards Application Profile
  • 77. Functional requirements Describe the functions that the application profile is designed to support as well as functions that are out of scope. Form the basis of evaluating the application profile for internal consistency Gives guidance on the appropriateness of the application profile for a given use.
  • 78. Example: ePrints Functional requirements Requirement: Provide a richer set of metadata than is currently possible with simple DC Requirement: Be compatible with preservation metadata approaches. Requirement: Support extensibility of the application profile for other types of material. Requirement: Implement an unambiguous method of identifying the full-text(s). Requirement: Support navigation between different 'versions' of the same eprint etc.
  • 79. Domain models Defines the basic entities described by the application profile and their fundamental relationships. Concretizes the scope for the application profile. The domain model can be expressed using just text or using a more formal approach such as UML. Does NOT say what properties to use
  • 81. Description Set Profiles Defines a set of metadata records that are valid instances of an application profile. The Description Set Profile model is currently being developed within the Dublin Core Architecture Forum Designed to offer a simple constraint language for Dublin Core metadata, based on the DCMI Abstract Model A DSP constrains the resources that may be described by descriptions in a description set conforming to the application profile, the properties that may be used, the ways a value may be referenced.
  • 82. Description Set Profiles A Description Set Profile can be used for purposes such as: formally representing constraints used in metadata configuring databases configuring metadata editing tools
  • 84. Statement template: literal title dcterms:title Literal value Language SES Property: Statement template: creator dcterms:creator Value string Language SES Property: Value URI Vocabulary Encoding Scheme Description reference: Creator Statement template: literal name foaf:name Literal value Language SES Property: standalone:no Description Template: Book Description Template: Creator
  • 85. Usage guidelines Usage guidelines describe how to apply the application profile How are the used properties intended to be used in the application context? What principles are used when gathering data? What other principles governs the implementation and use of the application profile
  • 86. Example: Collections description Guildelines for Title element: Where an existing name is used, the value string should preserve the original wording, order and spelling of an existing name. Punctuation need not reflect the usage of the original. Subtitles should be separated from the title by a sequence of space-colon-space, for example: Voices from the Dust Bowl: The Charles L. Todd and Robert Sonkin Migrant Worker Collection “
  • 87. DCMI specs for Application Profiles Singapore Framework http://dublincore.org/documents/singapore-framework/ Documentation guidelines, January 2008 Description Set Profiles http://dublincore.org/documents/dc-dsp/ Formal (machine-readable) part of Singapore Framework Working draft, March 2008 Implementation expercience still needed
  • 88. Summary Dublin Core metadata defined by different forms of “interoperability” For human understanding Machine semantics Metadata records Application Profiles Projects need to place themselves on this map What do I need? How can I achieve it? The Dublin Core community is open to implementers at all levels
  • 89. Dublin Core and other metadata schemas Mikael Nilsson < [email_address] >
  • 90. Interoperability Levels for Dublin Core metadata Level 1: Informal interoperability Shared concepts with natural-language definitions No use of formal models or term URIs Test: Is there a mapping to shared elements? Example: IEEE LOM reuses some definitions and maps to 15-element “Dublin Core” (ISO 15836)
  • 91. Interoperability Levels for Dublin Core metadata Level 2: Semantic Interoperability Correct use of formal RDF graph model with conformant vocabularies (eg DCMI Metadata terms) Use of URIs and formal semantic relationships between terms (eg subproperties) Test: Is there a mapping to RDF triples? Examples: All RDF data (by definition) All RDF data extracted from non-RDF formats (eg via GRDDL transforms) All XHTML or HTML data using RDFa or DC-HTML/2008.
  • 92. Interoperability Levels for Dublin Core metadata Level 3: Description set syntactic interoperability Level-2-compatible data packaged in bounded description sets (records) as per DCMI Abstract Model (DC-AM) Conventions for citing vocabulary encoding schemes (controlled vocabularies) Test: Is there a mapping to “Expressing Dublin Core metadata using the DC-Text format”? Examples: All data using DC-AM-compatible specifications, such as DC-DS-XML.
  • 93. Interoperability Levels for Dublin Core metadata Level 4: Description Set Profile Interoperability Level-3-compatible data that follows the specification “Description Set Profiles: A constraint language for Dublin Core Application Profiles” Additional interoperability via shared Functional Requirements and Domain Model (“Singapore Framework for Dublin Core Application Profiles”) Test: Is there a mapping to DSP constraints? Examples: Scholarly Works Application Profile
  • 94. Interoperability Levels for Dublin Core metadata Level 4: Description Set Profile Interoperability Level 3: Description Set syntactic interoperability Level 2: Semantic interoperability Level 1: Informal interoperability