DCMI Abstract Model: issues and proposed changes
-
Upload
eduserv-foundation -
Category
Education
-
view
1.257 -
download
2
description
Transcript of DCMI Abstract Model: issues and proposed changes
3 O
ctob
er 2
00
6
Pete Johnston, Eduserv [email protected]
www.eduserv.org.uk/foundation
DCMI Abstract Model: issues and proposed changesDCMI Architecture Working Group DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
2
Background
• DCMI Abstract Model– DCMI Recommendation March 2005
• DCAM describes– Components and constructs that make up an
information structure (“DC description set”)
– How that information structure is to be interpreted
• DCAM does not describe how to represent DC description set in concrete form
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
3
DCAM Description Model
• a description set is made up of one or more descriptions • a description is made up of
– zero or one resource URI and – one or more statements
• a statement is made up of – exactly one property URI and – zero or one reference to a value in the form of a value URI – zero or more representations of a value, each in the form of a value
representation – zero or one vocabulary encoding scheme URI
• a value representation is either – a value string or – a rich representation
• a value string may have an associated value string language • a value string may have an associated syntax encoding scheme URI • a value may be the subject of a related description
Resource URI
Property URI Rich representation
Property URI Value URI Vocab Enc Scheme URI
Property URIValue string Syntax Enc Scheme URI
Value string Syntax Enc Scheme URI
Resource URI
Property URI Rich representation
Property URI Value URI Vocab Enc Scheme URI
Property URI Value string Syntax Enc Scheme URI
Statement
Description
Description Set
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
5
DCMI Abstract Model in use
• Use of DCAM has generated comments from e.g.– DCMI Usage Board– DCMI Working Groups, particularly WGs developing DCAPs– Implementers of DCAPs– Developers/implementers of related specs (e.g. SKOS)– Researchers– Implementers of metadata registries– Authors/editors of “encoding guidelines” specifications– (and others!)
• Use of DCAM has – highlighted omissions, ambiguities, redundancies, errors– created better understanding of what is required– emphasised value of an abstract model!
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
6
Proposed changes
• Issues collated in• http://dublincore.org/architecturewiki/AMIssues
1. Some editorial/presentational change
2. Remove some historical information
3. Clarify existing concepts/constructs
4. Extend to include new concepts/constructs
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
7
Editorial/presentational change
• Purpose of DCAM– (Current) “The primary purpose of this document is to provide a
reference model against which particular DC encoding guidelines can be compared. To function well, a reference model needs to be independent of any particular encoding syntax. ”
– Doesn’t reflect role of DCAM in defining what DC metadata is, the nature of the components used, and how they are interpreted
– Also DCAM should be starting point for “encoding guidelines”– (Proposed) “The primary purpose of this document is to specify
the components and constructs used in Dublin Core metadata. It defines the nature of the components used and describes how those components are combined to create information structures. It provides a reference model which is independent of any particular encoding syntax.”
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
8
Editorial/presentational change
• Vocabulary Model– Description of types of terms and types of
relationships that exist between terms
– Based on RDF Schema
– Currently embedded in “Resource Model”/Figure 1
– Useful to make more explicit
– Also some extensions required (more later)
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
9
Remove some historical information
• Appendices contain discussion of specs based on earlier/different “abstract models”– e.g. appendices on encoding guidelines in 2003
– attempts to retrofit DCAM confusing (inaccurate?)
– redundant once DCMI adopts encoding guidelines based on DCAM
• Confused terminology in discussion of “structured values”– addressed in revisions to DCSV, Box, Period, Point
(2006)
• Useful for context of DCAM in 2003, but should not be part of document
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
10
Clarify existing concepts/constructs
• Phrasing of some definitions is inconsistent with usage in text e.g.– Term
• (Current) The generic name for a property (i.e. element or element refinement), vocabulary encoding scheme, syntax encoding scheme or concept taken from a controlled vocabulary (concept space).
• (Proposed) A property (i.e. element or element refinement), vocabulary encoding scheme, syntax encoding scheme or concept taken from a controlled vocabulary (concept space).
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
11
Clarify existing concepts/constructs
• Sub-property/Sub-class– Currently modelled as distinct classes
– Should be represented in Vocabulary Model as relationships between properties, classes
– i.e. same concepts as in RDF Schema
– Also provide definitions in glossary
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
12
Clarify existing concepts/constructs
• “Description Set”– Need to emphasise that “description set” is primary
“abstract information structure”– Proposal: Add “A description set is a set of one or more
descriptions” to textual description of description model • “Related description”
– Need to emphasise that a “related description” is just a description
– Proposal: use “description of value” etc • “Resource”/”Resource URI” and “Value”/”Value URI”
– A value is a resource, so sometimes use of “resource” seems ambiguous
– Proposal: use “described resource” to refer to subject of description
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
13
Clarify existing concepts/constructs
• Value strings, language tags & syntax encoding schemes– (Currently) allow value string to be associated with both
a language tag and a syntax encoding scheme (datatype)
– Proposal: permit value string to be associated with either language tag or syntax encoding scheme, or neither, but not both
• “Empty statements”– (Currently) allow a statement with no value URI or value
representation and no (“related”) description of value– Proposal: specify that value URI or value representation
must be provided unless value is subject of separate description
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
14
Clarify existing concepts/constructs
• Syntax encoding schemes– (Currently) A syntax encoding scheme indicates that the value
string is formatted in accordance with a formal notation, such as "2000-01-01" as the standard expression of a date.
– SES includes a “contract” for interpretation of literal– But “formatted” too narrow
• ISO 3166, xsd:Boolean, xsd:int
– Doesn’t capture notion that SES indicates that literal “stands for” something else
– Proposal: A syntax encoding scheme is a set of strings that is associated with a set of rules which describe a mapping between that set of strings and a set of resources. The mapping rules may be based on a description of how the string is structured (e.g. DCMI Box) or they may be based on a simple enumeration of all the strings and the corresponding resource (e.g. ISO 3166).
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
15
Extend to include new concepts/constructs
• Range/domain– DCMI plans to make range/domain assertions for
DCMI-owned properties• Making explicit to software what is implicit in
human-readable descriptions
– Should be added to Vocabulary Model as relationships between properties, classes
– i.e. same concepts as in RDF Schema
– Also provide definitions in glossary
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
16
Extend to include new concepts/constructs
• Vocabulary Encoding Scheme v Class of Value– (currently) VES = class of Value– Conflict with existing DCMI use of concept e.g.
• class of LCSH terms considered a VES• class of collections or class of persons not considered VES
– Also integration with SKOS• relation between Concept and ConceptScheme is
skos:inScheme not rdf:type (instance-of)• so difficult to use same resource as skos:ConceptScheme
and as VES– What distinguishes a VES from a Class?– Proposal: VES as enumerable set of resources– Proposal: Add Value Class URI to description model (in
addition to VES URI)
3 October 2006DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
17
Other issues not yet discussed
• Rich Representations & MIME types– Should DCAM description model specify that rich
representation should be associated with MIME type?
• “Conformance to DCAM”
3 O
ctob
er 2
00
6
Pete Johnston, Eduserv [email protected]
www.eduserv.org.uk/foundation
DCMI Abstract Model: issues and proposed changesDCMI Architecture Working Group DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico