Week 4 - Muddies Point:
I have D-space loaded onto my PC, but I am the only person able to see the images I have added. Do we have to network it so anyone can log on and see our DL? If so, how do we network it?
Julie
Saturday, September 25, 2010
Saturday, September 18, 2010
Wk 4 Readings
Wk 4 Readings | Presentation (Text) and Persistence (DOI)
This week's readings focused on presentation (Chapter 9, Arms), and "persistent" or long-term connection to a publication (Identifiers and Their Role in Networked Information Applications, Lynch and Digital Object Identifier System, Paskin) .
When thinking about Digital Libraries, text is sometimes overlooked; therefore, it was refreshing to read a focussed chapter regarding the presentation of text, then many challenges in presenting text, and the myriad mark-up methods with pros and cons e.g. html, xml, sgml, TeX, character recognition, PDFs, etc... Though in 2010 we are much closer to a true shift from print to digital since we are now living in the era of Kindle-esque applications where note taking, highlighting, and readability are realities. My colleagues at work were just discussing disappearing paper newspapers...
Of equal importance is the ability to consistently send the user to the correct document over time without error, and now I understand DOI a little better in that they do not change over time and that the DOI is the Handle System that helps to avoid the user ever landing on a broken link. I did not realize that DOI was trademarked, had a foundation, or was the result of the publishing industry's initiative in the early 90s (Paskin). The DOI / Handle systems sounded like a blessing (where do I get one and how do I secure my DL with it?) until I read Lynch's article about concerns about DOI's true intentions, e.g. whether it is geared toward acquiring and payment or for consistency in access to publications.
Questions:
1) How does a DL designer incorporate DOI?
2) Is there still ambiguity over DOI and its true purpose or value?
Muddies Point:
How will our own DLs work? When we design our own DL, will it be networked somehow or only available on our own PC where we take screenshots of our entries?
Julie
This week's readings focused on presentation (Chapter 9, Arms), and "persistent" or long-term connection to a publication (Identifiers and Their Role in Networked Information Applications, Lynch and Digital Object Identifier System, Paskin) .
When thinking about Digital Libraries, text is sometimes overlooked; therefore, it was refreshing to read a focussed chapter regarding the presentation of text, then many challenges in presenting text, and the myriad mark-up methods with pros and cons e.g. html, xml, sgml, TeX, character recognition, PDFs, etc... Though in 2010 we are much closer to a true shift from print to digital since we are now living in the era of Kindle-esque applications where note taking, highlighting, and readability are realities. My colleagues at work were just discussing disappearing paper newspapers...
Of equal importance is the ability to consistently send the user to the correct document over time without error, and now I understand DOI a little better in that they do not change over time and that the DOI is the Handle System that helps to avoid the user ever landing on a broken link. I did not realize that DOI was trademarked, had a foundation, or was the result of the publishing industry's initiative in the early 90s (Paskin). The DOI / Handle systems sounded like a blessing (where do I get one and how do I secure my DL with it?) until I read Lynch's article about concerns about DOI's true intentions, e.g. whether it is geared toward acquiring and payment or for consistency in access to publications.
Questions:
1) How does a DL designer incorporate DOI?
2) Is there still ambiguity over DOI and its true purpose or value?
Muddies Point:
How will our own DLs work? When we design our own DL, will it be networked somehow or only available on our own PC where we take screenshots of our entries?
Julie
Sunday, September 12, 2010
Wk 2 Readings
Wk 2 Readings | DL Interoperability - Challenges and Goals
The readings, which span an era from 1997 through 2001, show the complex process of keeping DL structures simple enough to be effective (to effectively allow communities to share information). The following is not meant to summarize, but rather to give examples of my observation:
In An Architecture for Information in Digital Libraries (1997), Arms, Blanchi, and Overly stress a continued need to build on simple three simple building blocks: digital objects, handles, and repositories.
In Interoperability for Digital Objects and Repositories (1999) Sandra Payette describes the collaboration between Cornell and the Corporation for National Research Initiatives (CNRI) and the exhaustive experiments, mostly successful, which resulted in the convergence of their two designs: Cornell's Fedora, and CNRI's Digital Object Respository Architecture yielding Repository Access Protocol (RAP) and the surprising finding that repositories do not need to be completely similar in functional design to be interoperable.
In A Framework for Building Open Digital Libraries (2001), Suleman and Fox explain that a lot is expected from DLs in the form of content management, but this is difficult when digital information is dynamic.
They emphasize that any interoperability that had been accomplished was primarily achieved due to the simplicity of OAI/PMH, and as DLs are forced to become more complex some extensibility may be lost.
The complexity we know today is probably the enemy of the efficient DLsystems as described in the above three articles. This brings me to my questions for next time:
QUESTIONS:
1) The articles range in date from 1997-2001. Is the Cornell/CNRI collaboration still ongoing, and is Fedora still considered to be an effective system in 2010?
2) What is happening with DLs right now? Are there other collaborations, and is complexity still the enemy of DL efficiency and usability?
Muddies Points:
1) With the many different ways of looking at DLs, how does a librarian choose one and then it seems as though there a many obstacles in the path before the DL is functional to a community. Does this mean that all DLs require a team of librarians and technical specialist to design each DL, and how do you know which ODL to use i.e. is there a way to match user needs with ODL type?
The readings, which span an era from 1997 through 2001, show the complex process of keeping DL structures simple enough to be effective (to effectively allow communities to share information). The following is not meant to summarize, but rather to give examples of my observation:
In An Architecture for Information in Digital Libraries (1997), Arms, Blanchi, and Overly stress a continued need to build on simple three simple building blocks: digital objects, handles, and repositories.
In Interoperability for Digital Objects and Repositories (1999) Sandra Payette describes the collaboration between Cornell and the Corporation for National Research Initiatives (CNRI) and the exhaustive experiments, mostly successful, which resulted in the convergence of their two designs: Cornell's Fedora, and CNRI's Digital Object Respository Architecture yielding Repository Access Protocol (RAP) and the surprising finding that repositories do not need to be completely similar in functional design to be interoperable.
In A Framework for Building Open Digital Libraries (2001), Suleman and Fox explain that a lot is expected from DLs in the form of content management, but this is difficult when digital information is dynamic.
They emphasize that any interoperability that had been accomplished was primarily achieved due to the simplicity of OAI/PMH, and as DLs are forced to become more complex some extensibility may be lost.
The complexity we know today is probably the enemy of the efficient DLsystems as described in the above three articles. This brings me to my questions for next time:
QUESTIONS:
1) The articles range in date from 1997-2001. Is the Cornell/CNRI collaboration still ongoing, and is Fedora still considered to be an effective system in 2010?
2) What is happening with DLs right now? Are there other collaborations, and is complexity still the enemy of DL efficiency and usability?
Muddies Points:
1) With the many different ways of looking at DLs, how does a librarian choose one and then it seems as though there a many obstacles in the path before the DL is functional to a community. Does this mean that all DLs require a team of librarians and technical specialist to design each DL, and how do you know which ODL to use i.e. is there a way to match user needs with ODL type?
Subscribe to:
Posts (Atom)