My "muddiest point" this week is installing and running greenstone. It appears that the only version available for mac is the web version, which requires me to download a web server called Apache...I've done so but am not sure what to do with Apache.
Maybe I am making things way more complicated than necessary, but some help would be appreciated!
Wednesday, September 17, 2008
Friday, September 12, 2008
Reading Notes week 3
I don't have all of the readings in front of me at the moment, so I'm going to just do a brief commentary on them as a whole.
I have to say that I'm still confused by the concept of DOI's. Unfortunately I read the Lynch article last...I feel like reading that one first would have perhaps made things a bit clearer. I understand the motivation behind developing a DOI system, in particular the concept of persistence. However, I do not necessarily how they would work. Lynch raised some good points that helped me to understand that this system is not yet fully fleshed out, and that was helpful. In particular the statement that "Today's standard browsers do not yet understand URNs and how to invoke resolvers to convert them to URLs, but hopefully this support will be forthcoming in the not too distant future."
I suppose one of the main things that confused me was the need for something similar to an ISBN for digital content. Perhaps (probably) I am over-simplifying things, but it seems to me that an ISBN or ISSN are necessary because large numbers of copies exist for printed works. For most digital content, only one or a small few copies exist and this/these can be accessed by multiple users concurrently. To be honest, I am not well versed in Intellectual Property or Copyright issues at all, and this is probably what is confusing me the most.
Another thing that stood out to me was the issue of not being able to learn an object's DOI unless the object carries it as a label. If I wanted to know the ISBN of a particular book, there are ways for me to find it by searching with other, known identifiers such as the title. It seems to me that there is a huge issue in general with the naming of web-based content. Digital files can be given filenames that could serve as some sort of searchable identifier, but in general web pages and sites that host digital content are haphazardly named and authoring information is inconsistently revealed, if at all.
Lesk and Arms Chapter 9 were straightforward and I do not really have much to say about them. In particular, Arms provided a good refresher for me on some concepts that I am somewhat familiar with, but could always learn more about!
I hope this was sufficient for this week's posting...
I have to say that I'm still confused by the concept of DOI's. Unfortunately I read the Lynch article last...I feel like reading that one first would have perhaps made things a bit clearer. I understand the motivation behind developing a DOI system, in particular the concept of persistence. However, I do not necessarily how they would work. Lynch raised some good points that helped me to understand that this system is not yet fully fleshed out, and that was helpful. In particular the statement that "Today's standard browsers do not yet understand URNs and how to invoke resolvers to convert them to URLs, but hopefully this support will be forthcoming in the not too distant future."
I suppose one of the main things that confused me was the need for something similar to an ISBN for digital content. Perhaps (probably) I am over-simplifying things, but it seems to me that an ISBN or ISSN are necessary because large numbers of copies exist for printed works. For most digital content, only one or a small few copies exist and this/these can be accessed by multiple users concurrently. To be honest, I am not well versed in Intellectual Property or Copyright issues at all, and this is probably what is confusing me the most.
Another thing that stood out to me was the issue of not being able to learn an object's DOI unless the object carries it as a label. If I wanted to know the ISBN of a particular book, there are ways for me to find it by searching with other, known identifiers such as the title. It seems to me that there is a huge issue in general with the naming of web-based content. Digital files can be given filenames that could serve as some sort of searchable identifier, but in general web pages and sites that host digital content are haphazardly named and authoring information is inconsistently revealed, if at all.
Lesk and Arms Chapter 9 were straightforward and I do not really have much to say about them. In particular, Arms provided a good refresher for me on some concepts that I am somewhat familiar with, but could always learn more about!
I hope this was sufficient for this week's posting...
about me =)
It occurred to me that since I missed the first class session and had to run out right at the end of last week's class (to get to another), I haven't really met anyone in this class yet. And to top it off, comcast had my internet off all week for no good reason! So, here's a little bit more about me, in case anyone is looking for a potential group member...
I grew up in Louisville, KY and then attended college at Emory University in Atlanta, GA. I have a BA in Linguistics and Psychology with a minor in Russian (although I've pretty much lost all ability to speak it, oops). I'm hoping to get a second masters in the not-too-distant future, most likely in cognitive science. I'd like to work in an academic library and focus on services for science/math.
After finishing my BA I worked at an educational non-profit organization teaching kids from 3rd-8th grade, and when I couldn't make rent on that "salary" anymore (ha) I took a job working for an advertising consultant doing generic office grunt work. I also did a good amount of publication and presentation design. I was graphics editor and then editor-in-chief of my college's humor magazine, so I have lots of experience with that sort of thing.
I never really thought of myself as especially tech-savvy, but recently I've decided that maybe I'm selling myself a bit short. I don't have any formal training in anything, but I can generally figure out most things that are put in front of me. As I mentioned, I have lots of design experience and can certainly contribute that.
I've thrown a couple of ideas for the project around in my head, but I'm basically open to anything. At the moment I'm still confused about copyright issues for the materials we use, so I'm not trying to get too attached to any one idea.
I am a talker. In case you didn't notice, ha. I can go on at length on pretty much any topic. But some things that I am most interested in are music (especially independent rock, hip-hop, and electronic stuff), crafts, magazines, pets (especially cats), kitschy robot stuff, and language.
I'll be out of town this weekend (back for class Monday), but feel free to email me if you'd be interested in working together.
I grew up in Louisville, KY and then attended college at Emory University in Atlanta, GA. I have a BA in Linguistics and Psychology with a minor in Russian (although I've pretty much lost all ability to speak it, oops). I'm hoping to get a second masters in the not-too-distant future, most likely in cognitive science. I'd like to work in an academic library and focus on services for science/math.
After finishing my BA I worked at an educational non-profit organization teaching kids from 3rd-8th grade, and when I couldn't make rent on that "salary" anymore (ha) I took a job working for an advertising consultant doing generic office grunt work. I also did a good amount of publication and presentation design. I was graphics editor and then editor-in-chief of my college's humor magazine, so I have lots of experience with that sort of thing.
I never really thought of myself as especially tech-savvy, but recently I've decided that maybe I'm selling myself a bit short. I don't have any formal training in anything, but I can generally figure out most things that are put in front of me. As I mentioned, I have lots of design experience and can certainly contribute that.
I've thrown a couple of ideas for the project around in my head, but I'm basically open to anything. At the moment I'm still confused about copyright issues for the materials we use, so I'm not trying to get too attached to any one idea.
I am a talker. In case you didn't notice, ha. I can go on at length on pretty much any topic. But some things that I am most interested in are music (especially independent rock, hip-hop, and electronic stuff), crafts, magazines, pets (especially cats), kitschy robot stuff, and language.
I'll be out of town this weekend (back for class Monday), but feel free to email me if you'd be interested in working together.
Muddiest Point - Week 3
I am still rather confused over the issue of using copyrighted materials for our term projects. It would be great if someone could go into detail about what types of materials are appropriate/ok to use and what are not...
Monday, September 8, 2008
An Architecture for Information in Digital Libraries
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
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
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
Subscribe to:
Posts (Atom)
