Download Aquifer MODS AA workshop

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Metadata and Technology/Architecture
Working Groups
DLF Aquifer Project
DLF Fall Forum
Providence, RI
November 14, 2008
Agenda
 Introductions and background
 MODS Guidelines
 Asset Actions
 Hands-on work
 MODS and/or Asset Actions
 Wrap-up
 Participants’ comments/questions
 Future of Asset Actions and other Aquifer activities
This is an interactive session!
 We’re here to help you implement Asset Actions and
MODS in your local environment
 Open your browser to:
http://tinyurl.com/dlfaqua
I’m going to introduce MODS.
 Stay tuned for Asset Actions.
Why MODS?
 Metadata aggregations have clearly demonstrated
more robust metadata will allow higher-level services.
 MODS attempts to strike a “happy medium.”
 DLF institutions should be among those best
positioned to implement standards like MODS.
Why MODS Guidelines?
 Everything is open to interpretation.
 To systematically interpret MODS for the purposes of
sharing metadata.
 To give some direction in cases where the decision is
arbitrary.
 An attempt to promote consistency.
 Yes, we know that’s impossible.
 But you have to start somewhere!
Yikes, that’s a lot!
 No institution can completely conform to a set of
externally-imposed guidelines.
 Levels of Adoption document helps:
 Separates what’s functional from what’s cosmetic.
 Connects features of metadata to functionality for end-
users these features support.
 We need your feedback!
MODS help available in this
session
 Implementing the Aquifer MODS Guidelines
 Generally
 According to the Levels of Adoption
 Mapping your native metadata to MODS
 Conceptual mapping
 Technical mapping using XSLT
Asset Actions: Goals
 Simple, low-barrier-to-entry method of exposing
digital library content and structure
 Not just a URL to a web presentation
 Versions of an image, pages of a book, scenes of a video
 Enable cross-content cross-tool interoperability
 Easier than METS profiles
 Similar to Fedora notion of “behaviors”
 Not Fedora-specific
Asset Actions: Origins
 Began out of discussions between UVA, Tufts, and
Northwestern in 2005
 Adopted by DLF Aquifer to help achieve “deep
sharing” of digital resources in 2006
 Asset Actions Prototype portal
 Implementation in DLF Aquifer American Social
History Online portal
Asset Actions
 Series of typed URLs providing access to “views” of an
object
 Expressed (currently) via XML document
 Grouped into Action Groups by format
Asset Action Groups
 Define sets of actions corresponding to various types
of digital objects
 Default
 Basic Image
 Addressable Image
 Structured Text
 Image Text (Paged Image)
Asset Action Groups
 Define sets of actions corresponding to various types
of digital objects
 Default
 Basic Image
 Addressable Image
 Structured Text
 Image Text (Paged Image)
Asset Action Groups: Examples
Default
getAssetDefinition
getPreview
getLabel
getDCRecord
getWebView
getDefaultContent
Basic Image
getThumbnail
getScreenSize
getMaxSize
getDynamicView
Asset Actions Example
Basic Image
getThumbnail
getScreenSize
getMaxSize
getDynamicView
Default
getAssetDefinition
getLabel
getDCRecord
getPreview
getDefaultContent
getWebView
Bashful girl in red velvet
DLF Asset Actions & OAI-ORE
 DLF-AA model provides semantics to express typed (labeled),
actionable URIs associated with an intellectual resource
 In the Web Architecture URIs identify Web resources,
so a DLF-AA package is a manifest of Web resources associated
with an intellectual resource such as a digital text or image
 “Open Archives Initiative Object Reuse and Exchange (OAI-ORE)
defines standards for the description and exchange of aggregations
of Web resources” – ORE abstract data model
 ORE aggregations are described by ORE Resource Maps (ReMs)
 OAI-ORE leaves typing of Web resources within an ORE
aggregation up to communities of use
 We can use DLF-AA semantics within context of OAI-ORE to create
ORE ReMs describing DLF-AA packages – i.e., ORE ReM becomes
manifest of URIs associated with an intellectual resource
DLF Asset Actions & OAI-ORE (2)
 A ORE ReM is not the same as a DLF-AA package
 Different data model & data model semantics
 DLF-AA package data model simpler, single purpose
 ORE ReM data model general-purpose, conforms better to core
principles of RDF & Web Architecture
 ORE-ReMs can be used to describe a range of different kinds of
aggregations, not just DLF-AA manifests
 However, ORE ReM model may be used to express a DLF-AA
manifest – so functionally, a ORE ReM can be used instead of a
DLF-AA package to deliver essentially the same information
** Note, to use DLF-AA semantics in ORE ReMs required registering info URIs, e.g.:
info:dlf/aquifer/assetActions/getPreview
Asset Actions Exercise
 Choose a sample image object
 Create Asset Action XML record containing Default
and Basic Image action groups
 Upload to the MODS / Asset Actions Explorer and
experiment
Hands-on work
http://tinyurl.com/dlfaqua