Presentation on theme: "Dublin Core for Museums Day 2 Paul Miller UK Office for Library & Information Networking Thomas Hofmann Australian Museums On- Line."— Presentation transcript:
Dublin Core for Museums Day 2 Paul Miller UK Office for Library & Information Networking Thomas Hofmann Australian Museums On- Line CIMI John Perkins
Overview for Friday March 26 The Dublin Core in 1999 Break CIMI and the Dublin Core Lunch Beyond Dublin Core Discussion, Review Q&A
Stabilising the Dublin Core Dublin Core has evolved rapidly; six international, interdisciplinary workshops Dublin, Ohio, USA. March Warwick, United Kingdom. April Dublin, Ohio, USA. September Canberra, Australia. March Helsinki, Finland. October Washington DC, USA. November
Stabilising the Dublin Core Dublin Core has evolved rapidly; expression in 27 different languages, including English, Arabic, Burmese, Czech, Danish, Dutch, Finnish, French, German, Greek, Indonesian, Japanese, Korean, Thai, and Turkish. Chinese (Big 5) version of at Chinese (simplified characters) version under development.
Stabilising the Dublin Core Dublin Core has evolved rapidly; with a wealth of implementations, all interpreting the evolving Core slightly differently, and making it improve each time Australian Government Locator Service (AGLS) Arts & Humanities Data Service (AHDS) and many more…
Stabilising the Dublin Core Dublin Core has evolved rapidly; from Thirteen initial elements to Fifteen today by adding Rights, splitting Subject & Description in two, and renaming Author to Creator.
(Re–) Introducing the Dublin Core u Title u Creator u Subject u Description u Publisher u Contributor u Date u Type u Format u Identifier u Source u Language u Relation u Coverage u Rights
Stabilising the Dublin Core Attempts are now being made to draw upon all this knowledge in a controlled manner, and to guide the development of Dublin Core a little bit more….
Directorate A Directorate has been formed at OCLC, consisting of Stu Weibel and Eric Miller. They are responsible for driving the whole process forward in consultation with the Advisory Committees.
Advisory Committees A Policy Advisory Committee has been established, consisting of significant individuals in communities aligned to the Dublin Core. Their job is to represent the interests of their communities and to guide the evolution of DC. John Perkins advocates cultural heritage issues on this group.
Advisory Committees A Technical Advisory Committee has been established, consisting of the chairs of various Dublin Core working groups, as well as some other people. Paul Miller advocates cultural heritage issues on this group.
DC–GENERAL The main discussion forum for Dublin Core is a mailing list called dc–general. In order to minimise discussion on this list, most of the work associated with moving Dublin Core forward has been devolved to a series of working groups. Some of these groups deal with issues specific to one or more Dublin Core elements, whilst others address more generic topics All of these lists are open for anyone to join, and they are the Dublin Core All previous DC lists no longer used.
Element Working Groups DC–AGENTS Deals with Creator, Contributor and Publisher DC–COVERAGE Deals with the Coverage element DC–DATE Deals with the Date element
Element Working Groups DC–FORMAT Deals with the Format element DC–RELATION Deals with the Relation element DC–SUBDESC Deals with the Subject and Description elements
Element Working Groups DC–TITLE Deals with the Title element DC–TYPE Deals with the Type element
Issue Working Groups DC–CITATION Deals with issues related to expressing bibliographic citations in Dublin Core DC–DATAMODEL Deals with formalising the underlying data model for Dublin Core. Currently concentrating on RDF.
Issue Working Groups DC–GUIDES Deals with issues related to creating generic and community–specific documentation for use of Dublin Core DC–IMPLEMENTORS For discussion of issues arising whilst trying to implement Dublin Core in real environments
Issue Working Groups DC–INTERNATIONAL Deals with issues related to expressing Dublin Core in languages other than English DC–ONE2ONE Deals with formalising the assumptions behind the Dublin Cores 1:1 model
Issue Working Groups DC–SCHEMA Attempting to clarify the relation between Dublin Core and similar models from groups such as IFLA and INDECS DC–STANDARDS Deals with the standardisation process for Dublin Core, concentrating specifically upon CEN, NISO and ISO accreditation.
Formalisation Dublin Core Web Site purl.org/dc/ Dublin Core Directorate DC Policy Advisory Committee DC Technical Advisory Committee Working Groups Stakeholder Communities DC-General Dublin Core Mail Server Based on a slide by Stu Weibel
Clarification and Stabilisation Fifteen Dublin Core elements currently defined by RFC 2413 ftp://ftp.isi.edu/in–notes/rfc2413.txt Element working groups currently trying to clarify these definitions will produce a new RFC (DC 1.1) concerned only with the 15 elements; not with any qualification or subelement structure will not substantially change the elements will clarify definitions in order to make them say what we always meant them to say.
Qualification and Substructure Syntax There have been many attempts to develop a syntax for expressing substructure within Dublin Core. For example;
Qualification and Substructure Syntax All are being used somewhere, but the Dublin Core community as a whole is yet to wholeheartedly endorse one approach. The Data Model group is working with the Resource Description Framework (RDF) in order to both clarify the underlying model for DC and to offer an XML–based means of expressing the elements, their values, and any desired substructure.
Qualification and Substructure Syntax R CIMI Presentation Title Creator dc: Paul Miller
Qualification and Substructure Syntax RDF specification XML specification (RDF is usually expressed in XML) Draft RDF Schema specification (will make it easier to express DC substructure) Dublin Core data model specification expected in April.
Element Qualifiers and Value Qualifiers rdf:Valuedc : Element R dcq:Type (element qualifier) dcq:Scheme (value qualifier) (previously known as TYPEs, SUBELEMENTs, and SCHEMEs)
Element Qualifiers and Value Qualifiers Created dcq:DateType 1999–03–26 rdf:Valuedc:Date Resource ISO 8601 dcq : Scheme
Qualification and Substructure Values Dublin Core community advocates use of existing term lists where possible, rather than the invention of new ones so use AAT if it has the terms you need, rather than inventing a new thesaurus of museum terms Continuing pressure to create approved lists of element and value qualifiers, but it is proving difficult to make these sufficiently generic.
DC and CIMI Paul Miller UK Office for Library & Information Networking Thomas Hofmann Australian Museums On- Line CIMI John Perkins
Dublin Core and the museum community Challenges for museums Emphasis on attributes of the physical object (artefact) Need to associate the physical object with persons, places and events Need to account for collections Need to account for surrogates such as photographs Historical lack of content standards Assumptions regarding DC DC is useful to describe artefacts and associated information resources in the museum community DC is simple to use and learn Adequate technical infrastructure exists to support use of resource discovery
Testbed Phase I Goals Evaluate feasibility of DC for museum community Identifying and resolving operational, technical and intellectual issues Promote international consensus on DC practices in museum community Introducing the CIMI testbed project (I)
Milestones Involvement of over 18 participants (Software vendors, Museums, Consultants, Cultural Heritage Gateways) Over 300,000 record repository (museums, collections, artefacts) using DC Simple, both created from scratch and exported from legacy systems Guide to Best Practice: Dublin Core Introducing the CIMI testbed project (I)
Outcomes DC is easy to use DC simple is a machete, not a scalpel All Elements depend on Resource Type DC can be applied to both physical and electronic resources Further user evaluation necessary Introducing the CIMI testbed project (I)
Testbed Phase II Goals Finalisation and publication of Guide to Best Practice: Dublin Core Identification of proposed qualified elements (sub–structure) Examination of RDF Initial effort in mapping DC elements to CIMI Access Points New set of sample records (at ADLIB) User evaluation Introducing the CIMI testbed project (II)
Milestones There are four meetings scheduled for Please see for updates on the testbed phase II Introducing the CIMI testbed project (II)
Outcomes The schedule for 1999 for sees the following deadlines: Guide publication (April) DC recommendation (December) DC to CIMI Access Points mapping (November) RDF examination (July) Choreographed demonstration/ user evaluation (October) Final report and recommendations (December) For updates please see Introducing the CIMI testbed project (II)
About the Guide to Best Practice: Dublin Core Basis for the Guide: Based on Dublin Core 1.0 (RFC 2413) Recommendations based on testbed experience, not large scale production efforts Syntax used in examples and testbed based on XML Document structure: 15 DC simple elements starting with TYPE to assist in following the 1:1 rule (original vs. surrogate) Each element: - Introduced with standard DC Definition (RFC 2413) - Explained with CIMI Interpretation - Manifested with CIMI Guideline - Illustrated through Examples Appendices contain sample records for different types of museum describing a variety of resource types
Beyond Dublin Core Paul Miller UK Office for Library & Information Networking Thomas Hofmann Australian Museums On- Line CIMI John Perkins
The Dublin Core in context Dublin Core was originally developed as a tool for the discovery of electronic resources although now extended to physical objects, it is still about resource discovery Other initiatives fulfil similar niche roles, such as rights management metadata, administrative metadata, etc. Some initiatives are far more complex, and encompass many of these roles within a single implementation. How do we integrate and interoperate?
Extending the Dublin Core The fifteen basic elements of the Dublin Core are extensible, optional, and repeatable. Many implementors have extended these elements through the addition of substructure (AMICO…) Others have added whole new elements to the core in order to meet their needs The Admin Core, for example, is aimed specifically at the metadata kept in order to manage data where do we stop extending and use something else instead?
Other niche metadata markets Resource Discovery is one niche market Others include rights (INDECS…) description of educational content (IMS, GEM…) ratings (PICS…) How do these relate to Dublin Core?
Detailed museum approaches There are several cultural heritage developments which attempt to encompass far more than resource discovery How can they be interconnected, whether semantically or technically? SPECTRUM
The Dublin Core filter A User A Resource spatially discrete? Dublin Corefilter DC.title DC.creator DC.subject DC... mapping/ crosswalk
The Dublin Core filter Working together, we can map from detailed descriptions and methods up to the Dublin Core. Creator Subject Coverage... Artists Name Type of Work Period depicted Place depicted... Surname Forename Title...
The Dublin Core Filter Assuming that a satisfactory mapping can be defined, the Dublin Core therefore becomes a common language of access to more detailed resources, without the need for institutions to change their systems.
The Warwick Framework and RDF The Warwick Framework concept from the second Dublin Core workshop is realised in RDF Under this model, it becomes possible to bolt packages of metadata together in a near–seamless fashion. DescriptionArchival Management Terms & Conditions Based on a slide by Stu Weibel