Main bldg blocks: digital objects, handles, repositories
Purpose of IA is to rep riches & variety of library info
-digital object: way of structuring info in dig form, some of which may be metadata & includes a unique identifier called a handle.
-DOs often in sets, structure depends on info
-material can be devided into cat's (SGML, WWW objects, comp prog;s, digitized radio prog's etc)
-user interface: browser & client svcs
-repository: interface called Repository Access Protocol
-handle system: unique indentifiers
-search system
Issues in structuring info:
-dig materials frequently related to others by relationships (part/whole etc)
-same item may be in different formats
-diff versions created often (mult copies, or time-based)
-obj's have diff rights & permissions
-users access from diff comp sys's & networks
key-metadata: info to store, replicate, transmit obj w/out providing access to the content. includes terms & cond's and handle
digital material: used to store DL materials
Showing posts with label week 2. Show all posts
Showing posts with label week 2. Show all posts
Monday, September 8, 2008
A Framework for Building Open Digital Libraries
"Open" DLs build directly on concepts/philosophies of Open Archives Initiative
Most existing systems classified as DLs resulted from custom-built software dev projects - each involves intensive design, implementation & testing cycles.
- why repeat effort?
- some software toolkits: Dienst, Repository-in-a-box
Most programming environments adopt a component model
Oct 1999 - OAI launched.
- focus on high-level communication among systems & simplicity of protocol
- OAI protocol for Metadata Harvestingn (OAI-PMH): system of interconnected components
- OAI protocol can be thought of as glue that binds together components of a larger DL (or collaborative system of DLs)
DLs modeled as networks of extended OAs, with each OA being a source of data and/or provider of services.
- this approach closely resembles the way physical libraries work
- research & production DLs differ
ODLs guided by a set of design principles & operationalized with aid of OAI-PMH extensions. proven techniques from internet development
- simplicity of protocols, oppeness of standards, layering of semantics, independence of components, loose coupling of systems, purposeful othogonality, reuse
Formal Principles:
1) All DL svcs should be encapsulated w/in components that are extensions of OAs
2) All access to DL svcs should be through their extended OAI itnerfaces
3) Semantics of OAI Protocol should be extended or overloaded as allowed by OAI protocol, but w/out contradicting essential meaning
4) All DL svcs should get access to other data sources using extended OAI protocol
5) Dls should be constructed as networks of extended OAs
OAI Harvester obtains datastream which creates indices for searching.
Components in prototype systems:
- Union: combine metadata from mutl src
- Filter: reformat metadata from non-OAI data srcs
- Search: search-engine functionality
- Browse: bategory-driven browsing fx'lity
- Recent: sample of recently-added items
Tested on NDLTD system - good feedback
Designing by principles & implementing for real-world scenario
Most existing systems classified as DLs resulted from custom-built software dev projects - each involves intensive design, implementation & testing cycles.
- why repeat effort?
- some software toolkits: Dienst, Repository-in-a-box
Most programming environments adopt a component model
Oct 1999 - OAI launched.
- focus on high-level communication among systems & simplicity of protocol
- OAI protocol for Metadata Harvestingn (OAI-PMH): system of interconnected components
- OAI protocol can be thought of as glue that binds together components of a larger DL (or collaborative system of DLs)
DLs modeled as networks of extended OAs, with each OA being a source of data and/or provider of services.
- this approach closely resembles the way physical libraries work
- research & production DLs differ
ODLs guided by a set of design principles & operationalized with aid of OAI-PMH extensions. proven techniques from internet development
- simplicity of protocols, oppeness of standards, layering of semantics, independence of components, loose coupling of systems, purposeful othogonality, reuse
Formal Principles:
1) All DL svcs should be encapsulated w/in components that are extensions of OAs
2) All access to DL svcs should be through their extended OAI itnerfaces
3) Semantics of OAI Protocol should be extended or overloaded as allowed by OAI protocol, but w/out contradicting essential meaning
4) All DL svcs should get access to other data sources using extended OAI protocol
5) Dls should be constructed as networks of extended OAs
OAI Harvester obtains datastream which creates indices for searching.
Components in prototype systems:
- Union: combine metadata from mutl src
- Filter: reformat metadata from non-OAI data srcs
- Search: search-engine functionality
- Browse: bategory-driven browsing fx'lity
- Recent: sample of recently-added items
Tested on NDLTD system - good feedback
Designing by principles & implementing for real-world scenario
Interoperability for Digital Objects & Repositories
Cornell & CNRI: open architecture, confederated DLs, goal of interoperability & extensibility. Allows flexible interaction of existing services & augmentation of the infrastructure with new services.
Interoperability: broad problem domain. typically investigated w/in specific scope (comminity, classification of info, IT area, etc)
- creating a general framework for info access & integration across domains
- goal to enable communities w/ different info & tech to achieve general level of info sharing
Definition: ability of DL components of services to be functionally & logically interchangeable by virtue of their having been implemented in accordance with a set of well-defined, publically known interfaces.
some approaches:
1) standardization
2) distributed object request architectures (eg COBRA)
3) remote procedure calls
4) mediation
5) mobile computing
Cornell/CNRI approach:
1) agreement on common abstractions
2) definition of open interfaces to services/components that implement the abstractions
3) creation of extensibility mechanism for introducing new functionality into arch w/out interfering w/ core interoperability
Principle abstractions:
1) repository: different content managed in uniform manner
2) Digital Object: datastreams/elements (MIME sequence in bytes)
3) Disseminator: extend behavior of DOs & enable interaction
4) AccessManager
Disseminator Types: set of op's that extends basic functionality of a DO. (book - "get next page" "translate text" etc)
- signatures
- DOs can be used to make diss types avail in interface
Servlets: executable program capable of performing the set of op's defined for specific diss types.
- equivalence achieved when diff servlets operate on diff types of underlying datastreams to produce equivalent results.
- stored & registered in infrastructure in uniquely named DO
Extensibility: key is clean seperation of object structre, diss types, & mechanisms taht implement extended functionality.
- can endow DO w/ additional functionality
- new interfaces can be added
Interoperability Experiments:
- IT0: Protocol & Syntactic Interoperability
-IT1: Functional & Semantic
- 1.1: DO Access
- 1.2: DO Creation
- 1.3 Extensible Access
- IT2: Interoperability of Extensibility Mechanisms.
- 2.1: Ability to dynamically load signatures & servlets
- 2.2: Demonstrate flexibility w/ which new diss types are dynamically added to infrastructure
Interoperability: broad problem domain. typically investigated w/in specific scope (comminity, classification of info, IT area, etc)
- creating a general framework for info access & integration across domains
- goal to enable communities w/ different info & tech to achieve general level of info sharing
Definition: ability of DL components of services to be functionally & logically interchangeable by virtue of their having been implemented in accordance with a set of well-defined, publically known interfaces.
some approaches:
1) standardization
2) distributed object request architectures (eg COBRA)
3) remote procedure calls
4) mediation
5) mobile computing
Cornell/CNRI approach:
1) agreement on common abstractions
2) definition of open interfaces to services/components that implement the abstractions
3) creation of extensibility mechanism for introducing new functionality into arch w/out interfering w/ core interoperability
Principle abstractions:
1) repository: different content managed in uniform manner
2) Digital Object: datastreams/elements (MIME sequence in bytes)
3) Disseminator: extend behavior of DOs & enable interaction
4) AccessManager
Disseminator Types: set of op's that extends basic functionality of a DO. (book - "get next page" "translate text" etc)
- signatures
- DOs can be used to make diss types avail in interface
Servlets: executable program capable of performing the set of op's defined for specific diss types.
- equivalence achieved when diff servlets operate on diff types of underlying datastreams to produce equivalent results.
- stored & registered in infrastructure in uniquely named DO
Extensibility: key is clean seperation of object structre, diss types, & mechanisms taht implement extended functionality.
- can endow DO w/ additional functionality
- new interfaces can be added
Interoperability Experiments:
- IT0: Protocol & Syntactic Interoperability
-IT1: Functional & Semantic
- 1.1: DO Access
- 1.2: DO Creation
- 1.3 Extensible Access
- IT2: Interoperability of Extensibility Mechanisms.
- 2.1: Ability to dynamically load signatures & servlets
- 2.2: Demonstrate flexibility w/ which new diss types are dynamically added to infrastructure
Arms chapter 2
I really enjoyed this article as a refresher on some concepts that I'm familiar with, but hadn't known all the specifics about.
*****
Internet- collection of networks. LAN & Wide-Area Networks. Based on protocol of ARPAnet (TCP/IP)
*IP: Internet Protocol. joins together network segments that constitute internet. Four numbers, each 0-255 stored as 4 bytes. Connected by routers. Info in packets.
*TCP: Transport Control Protocol. Divides msg into packets, labels each w/ destination IP & Sequence #, sends them out on network. Receiving comp acknowledges receipt & reassembles.
- guarantees error-free delivery, but not prompt.
TCP/IP Suite of Programs:
*Terminal Emulation: telnet
*File Transfer: FTP
*Email: SMTP (single message)
Scientific publishing on the internet:
*RFC's (request for comment)
*IETF (Internet Engineering Task Force
*Los Alamos E-print archives
HTML, HTTP, MIME, URLs
*MIME specifies data type.
Conventions:
*web sites
*home page
*buttons
*hierarchical organization
web is giant step to build DLs on...not just detour until real thing comes along
*****
Internet- collection of networks. LAN & Wide-Area Networks. Based on protocol of ARPAnet (TCP/IP)
*IP: Internet Protocol. joins together network segments that constitute internet. Four numbers, each 0-255 stored as 4 bytes. Connected by routers. Info in packets.
*TCP: Transport Control Protocol. Divides msg into packets, labels each w/ destination IP & Sequence #, sends them out on network. Receiving comp acknowledges receipt & reassembles.
- guarantees error-free delivery, but not prompt.
TCP/IP Suite of Programs:
*Terminal Emulation: telnet
*File Transfer: FTP
*Email: SMTP (single message)
Scientific publishing on the internet:
*RFC's (request for comment)
*IETF (Internet Engineering Task Force
*Los Alamos E-print archives
HTML, HTTP, MIME, URLs
*MIME specifies data type.
Conventions:
*web sites
*home page
*buttons
*hierarchical organization
web is giant step to build DLs on...not just detour until real thing comes along
Thursday, September 4, 2008
Suleman & Fox: A Framework for Building Open Digital Libraries
-- "Open" DLs build directly on concepts/philosophies of Open Archives Initiative.
-- Most existing systems classified as DLs resulted from custom-built software dev projects - each involves intensive design, implementation & testing cycles. why repeat effort? some software toolkits: Dienst, Repository-in-a-box etc
-- Most programming enviro's adapt a component model.
-- OAI launched october 1999. Focuse on high-level comm among systems & simplicity of protocal.
-- OAI protocol for Metadate Harvesting (OAI-PMH): system of interconnected components. OAI protocal can be thought of as glue that binds together components of a larger DL (or collaborative system of DLs)
** DLs modeled as networks of extended OAs, with each OA being a source of data and/or provider of services. This approach closely resembles the way physical libraries work.
-- research & production DLs differ
-- ODLs guided by a set of design principals & operationalized with aid of OAI-PMH extensions. proven techniques from internet development: simplicity of protocols, openness of standards, loose coupling of systems, purposeful orthogonality, reuse whenever possible.
-- Formal Principals:
1. All DL services should be encapsulated within components that are extensions of OAs
2. All access to DL services should be through their extended OAI interfaces
3. Semantics of OAI protocol should be extended or overloaded as allowed by OAI protocol, but without contradicting essential meaning.
4. All DL services should get access to other data sources using extended OAI protocol
5. Dls should be constructed as networks of extended OAs.
-- OAI Harvester obtains data stream which creates indices for searching.
-- Components in prototype systems:
1. Union: combine metadata from mult sources
2. Filter: reformat metadata from non-OAI data sources
3. Search: search-engine functionality
4. Browse: category-driven browsing functionality
5. Recent: sample of recently added items
-- Tested on NDLTD system w/ good feedback.
-- Designing by principles & implementing for real-world scenario.
-- Most existing systems classified as DLs resulted from custom-built software dev projects - each involves intensive design, implementation & testing cycles. why repeat effort? some software toolkits: Dienst, Repository-in-a-box etc
-- Most programming enviro's adapt a component model.
-- OAI launched october 1999. Focuse on high-level comm among systems & simplicity of protocal.
-- OAI protocol for Metadate Harvesting (OAI-PMH): system of interconnected components. OAI protocal can be thought of as glue that binds together components of a larger DL (or collaborative system of DLs)
** DLs modeled as networks of extended OAs, with each OA being a source of data and/or provider of services. This approach closely resembles the way physical libraries work.
-- research & production DLs differ
-- ODLs guided by a set of design principals & operationalized with aid of OAI-PMH extensions. proven techniques from internet development: simplicity of protocols, openness of standards, loose coupling of systems, purposeful orthogonality, reuse whenever possible.
-- Formal Principals:
1. All DL services should be encapsulated within components that are extensions of OAs
2. All access to DL services should be through their extended OAI interfaces
3. Semantics of OAI protocol should be extended or overloaded as allowed by OAI protocol, but without contradicting essential meaning.
4. All DL services should get access to other data sources using extended OAI protocol
5. Dls should be constructed as networks of extended OAs.
-- OAI Harvester obtains data stream which creates indices for searching.
-- Components in prototype systems:
1. Union: combine metadata from mult sources
2. Filter: reformat metadata from non-OAI data sources
3. Search: search-engine functionality
4. Browse: category-driven browsing functionality
5. Recent: sample of recently added items
-- Tested on NDLTD system w/ good feedback.
-- Designing by principles & implementing for real-world scenario.
ARMS ch. 2 - link broken?
I'm having trouble accessing the ARMS ch. 2 reading. The link brings up an error message on the site that the article cannot be found. Is anyone else having this problem?
(also posted to Bb discussion board)
(also posted to Bb discussion board)
Subscribe to:
Posts (Atom)
