Week 11 Readings

Articles

Paepcke, A., H. Garcia-Molina, and R. Wesley. (2005, July/August). “Dewey Meets Turing: Librarians, Computer Scientists, and the Digital Libraries Initiative.” D-Lib Magazine 11: 7-8.

             A. Paepcke and his co-authors (2005), unusually, view the Web very negatively in the article. In terms of the Digital Library Initiative (DLI), they portray the Web as the disrupter of peace and alliance between computer scientists and librarians. It was the “somewhat undisciplined teenager,” a new son/daughter in terms that it has ruined their plans for their initiative by providing alternate sources of information (Paepcke, Garcia-Molina, and Wesley, 2005, under “The Cuckoo’s Egg Surprise,” para. 2). It challenged their assumptions about forming digital libraries and what was considered the primary source for finding and using materials. Yet Parpcke and his colleagues direct their analogy into an Oedipus/Elektra complex. The ‘teenager’ now has “sex appeal” for computer scientists; the Web offered a fertile area for machine learning, statistical, and experimental methods to become applicable to information search and organization, drawing in legions of researchers to participate (Paepcke, Garcia-Molina, and Wesley, 2005, under “The Cuckoo’s Egg Surprise,” para. 8). So it seduced computer scientists to the other side, leaving librarians off-balance in the Initiative. As such, it has become an adulterer, betraying the trust computer scientists and librarians had. Such language seems over-dramatic, though; the authors want to explain why digital libraries aren’t succeeding as they expected, so they found a scapegoat in the Web and made it the source of all of their troubles. I think a lot more factors are involved. Additionally, the Web is not the librarians’ enemy; it may cause hardships for the Initiative overall, but it has increasingly become a tool for librarians to use in linking, organizing, and creating information.

 

Lynch, C. A. (2003, February). “Institutional Repositories: Essential Infrastructure for Scholarship in the Digital Age.” ARL no. 226: 1-7.

             It is interesting that C.A. Lynch (2003) sets up the repository as a collaborative effort. He specifically states that a successful institutional repository portrays a collaboration between librarians, information technologists, archives and records managers, faculty, and university administrators and policymakers (Lynch, 2003, p. 2). This is interesting in that he takes a overarching viewpoint of the repository; rather than focusing on one identity or how one particular group of people creates or uses the institution, he suggests that it involves the work of many individuals. Thus the institutional repository does not appear to be so 2-dimensional, but more complex, requiring the actions of many people to work. This does fit its purpose to disseminate digital materials to its institution and related members – particularly the intellectual works of faculty and students (Lynch, 2003, p. 2) – in a sense implying that collaboration supplies benefits to a wider sample of people. I wonder, though, if institutional repositories should only distribute the works of faculty and students. Such a narrowing of focus may help the repository focus its aim to build up a collection and access to scholarship, but it also limits what counts as legitimate sources or information.

            Another interesting point is Lynch’s concerns over the use of repositories. The main troubles he foresees includes degenerating the repository into a tool for institutional control over intellectual work (Lynch, 2003, p. 4-5), adding additional “distracting and irrelevant policy baggage” to it (Lynch, 2003, p. 5), and – with increasing demand for institutional repositories – repositories may became hastily-made, hollow services (Lynch, 2003, p. 6). Thus he is concerned over the quality of institutional repositories; he associates a true repository as one little influenced by the politics of its institution [being almost ‘uncontaminated’ or pure, having its own agenda rather than fulfilling the agendas of its institution], yet requiring the full support and resources of its institution to be well-made and resourceful for its users. Can such conflicting worries coexist? Such a repository imagined by Lynch would need to be created by an institution which upholds values of open access to information and ideals on unrestrained/uncensored information. Reality, though, means that the repository in question has to submit to its institution to some degree if it is to receive funding or support in its own endeavors. As such, I don’t know how realistic Lynch’s concerns are or if they can be fixed according to his own values.

 

Hawking, D. (2006, June). “Web Search Engines: Part 1.” Computer: 86-88.
AND
Hawking, D. (2006, August). “Web Search Engines: Part 2.” Computer: 88-90.

             According to D. Hawking (2006), Web search engines require a lot of attention and work to operate. Physically, they can be sprawling. Each operates from numerous, geographically spread data centers and within each center are a variable number of servers to support services and specialized duties (Hawking, “Part 1,” 2006, p. 86). Thus search engines are not one entity, but a composition of entities; it needs different parts to ensure that it functions as it should. Its actions itself imply complexity as well. For example, search engines employ inverted files to identify indexing terms. Inverted files can only be created in two phases – first, scanning the text of each input document; second, sorting temporary files into term number order (Hawking, “Part 2,” 2006, p. 88). This requires a user to invest of lot of time and attention to create the files needed for the process. Taken altogether, this is a sobering thought; search engines have become such a common feature on the Web that to not see one would be a cause for outcry. It seems so easy to use – just enter a word or phrase, click, and you get your results – yet a lot of work goes into making sure it works.

 

Shreeves, S.L., T.G. Habing, K. Hagedorn, and J.A. Young. (2005). “Current Developments and Future Trends for the OAI Protocol for Metadata Harvesting.” Library Trends 53, no. 4: 576-589.

             In this article, I found the development of OAI services quite interesting. Rather than remain a tool only in the e-print archives community, others – libraries, museums, archives, etc. – started using it for their own services, creating user group-specific service providers (Shreeves et al, 2005, p. 578). Thus others started seeing its usefulness – probably through observing how the e-print archives community used it and debated its pros/cons. Yet, other communities didn’t mimic the original users explicitly. Rather, they not only utilized the servers to help provide federated access to resources but also developed further standards, tools, and metadata schemas to contribute to the OAI protocol (Shreeves et al, 2005, p. 578). In this way, the OAI provides a good lesson in using technologies, especially those created for a specific purpose or group. If others purposes exist for a device, then a user should test it out. Other people can use the same tool for different purposes. Additionally, what it is now does not mean that it will maintain that structure in the future; users can add new standards or other accessories to the technology to better adapt it to their situation.

October 28's Muddiest Point

I'm still a little confused about the role of CSS Comments (slide 30). How do the Comments explain the code used? Why are they ignored by the browsers?

Week 10 Readings

Articles

Bryan, M. (1997). “An Introduction to the Extensible Markup Language (XML).” The SGML Centre. Retrieved from http://www.is-thought.co.uk/xmlintro.htm.

             M. Bryan (1997) notes a very integral facet – scrupulousness – of the XML language. While he relates the multiplicity of XML languages available, as is considered in the other readings for this week, Bryan also states that XML can transfer information about the component parts of documents to other computer systems and is malleable enough to describe any logical text structure – memos, letters, dictionaries, databases, and the like (Bryan, 1997, under “What is XML?,” para. 6). At the same time, it identifies where the change of appearance happens, where a new element begins, and what boundaries exist for each part of a document (ibid., under “The components of XML,” para. 2). Thus XML is thorough. It concentrates on the individual parts of information – providing equal attention to each cog and not skipping over different key components – and covers a wide range of text structures representing a multitude of information types. Additionally, it sets up to mark everything – its beginnings, its endings, and its limits, to name a few. Such meticulousness ensures that all information is explained and moved entirely to other computers.

 

Ogbuji, U. (2004, January 20). “A survey of XML Standards: Part 1, The core standards – a foundation for the wide world of XML.” IBM: developerWorks. Retrieved from http://www.ibm.com/developerworks/library/x-stand1/index.html

             U. Ogbuji (2004) highlights an important factor in understanding not only his survey, but also in interpreting XML. Rather than assume that he and his users will read his article in the same way, he defines what he means by “standards” in his introduction. Ogbuji sustains “that the word itself is a bit slippery,” having multiple forms, but that he himself “follow[s] the practical approach of defining a standard as any specification that is significantly adopted by a diversity of vendors, or is recommended by a respectable, vendor-neutral organization” (Ogbuji, 2004, para. 2). According to Ogbuji, there exists no customary “language” for determining XML Standards or its related premises – that even its subject of standards remains vague if no one actively elaborated on the topic. Yet he assumes that he is taking the “practical approach” – the more logical, possibly superior method of interpretation – for defining the word. While attempting to make the concept clearer is inarguably beneficial in this context, ensuring that readers have a clearer idea on how to analyze his article, such a viewpoint remains one bias on how to read it. It is good that he provides a definition, but what he may deem as “practical” may not be so in the overarching framework on XML discussion.

            Continuing along this concept of language (albeit within XML itself), the use of namespaces offers ways to manipulate vocabulary. Namespaces themselves can assign a vocabulary marker to each XHTML element, allowing the user to differentiate elements from the host vocabulary elements which use the same names (Ogbuji, 2004, under “XML Namespaces”). Such a method is fascinating in that it links standardized languages between levels. Namespaces acknowledge the issue that sometimes the official vocabulary repeats itself, confusing the contents of the document as a whole. Thus it provides markers that follow another standardization. Although complex in practice – or, as Ogbuji notes, a controversial move that may cause more problems than it should (ibid.), it does provide a framework for viewing how different forms of standard languages interact. Thus it may not be beneficial when a person needs to use it, but it is useful for theoretical analyses.

 

Bergholz, Andre. (2000, July-August). “Extending Your Markup: An XML Tutorial.” IEEE Internet Computing: 76-79. Retrieved from http://xml.coverpages.org/BergholzTutorial.pdf.

             Out of all of the articles required for this week, I believe that A. Bergholz (2000) provides one of the clearest definitions for XML and what it does. Specifically, he asserts that XML is “a semantic language that lets you meaningfully annotate text,” making it easier for users and computers to understand (Bergholz, 2000, p. 74). This is clearer than how the “XML Tutorial” (n.d.) of W3Schools describes XML. XML annotates – making comments, marking points with more in-depth descriptions that ensures smoother computation. This particular definition is also succinct, pinpointing the key characteristics of XML that a user would need to know to differentiate it from other concepts.

            What was new for me was XSL. Bergholz (2000) introduces XSL – the Extensible Stylesheet Language – as a complex of two languages, XSL transformations (or XSLT) and XSL formatting objects/language (p. 77-78). As far as I know, I have never heard about XSL. So reading about XSL proved most informative. Specifically, users can utilize XSLT to transform XML into HTML and reformat XML documents so that a variety of XML representations are mapped onto each other (Bergholz, 2000, p. 78). XSLT, in this manner, is relatively powerful. Although it cannot change the basic nature of HTML or XML, XSLT can reform its approach and appearance contrary to their character. I don’t know whether Bergholz’s claim that XSLT especially helps electronic commerce and electronic data interchange (ibid., p. 78) is true – I don’t have the necessary background and education to decide – but the premise sounds possible; if XSLT can reformat XML into different forms, then it can provide a wider range of documents that can be read more easily.

 

“XML Tutorial.” (n.d.). w3schools.com. Retrieved from http://www.w3schools.com/xml/default.asp

            Similar to Uche Ogbuji’s article “A Survey of XML Standards: Part 1,” the “XML Tutorial” (n.d.) focuses on the manipulation of language and how users can use it. It specifically acts as a markup language, carrying data (not displaying it) and remaining self-descriptive (“XML Tutorial,” n.d., under “Introduction to XML,” “What is XML?”). Thus it has its own vocabulary, acting as a method of communication between user and computer. The Tutorial, however, argues that it “does not do anything;” it can “structure, store, and transport information” but “it is just information wrapped in tags,” needing additional software to either send, receive, or display it (ibid., “XML Does Not DO Anything”). Compared to Bergholz’s definition (Bergholz, 2000, p. 74), this definition isn’t as clear. I think I understand the basic meaning the Tutorial purports – that XML only marks up the structure and describes features, not actually commanding anything to be done – but I think that stating that it “does not do anything” confuses more than explains XML.

            The language of XML itself seems to be its own creation. It is very fertile; since the XML language does not have any predefined tags, the user can determine her own tags and document structure (“XML Tutorial,” n.d., under “Introduction to XML,” “With XML You Invent Your Own Tags”), so the number of XML language possible is limitless (ibid., under “How Can XML be Used?,” “XML is Used to Create”). As such, XML is almost alive, allowing users to create multiple languages to attain different purposes. A few rules still apply. For example, XML tags are case-sensitive (ibid., under “XML Syntax Rules,” “XML Tags are Case Sensitive”) and all attribute values have to be quoted (ibid., “XML Attribute Values”). So some limits exist, restricting the number and type of possible languages available. However, some restrictions are necessary so that XML language creation does not become too chaotic, following some basic pattern to work in practice and having an anchor in what does and doesn’t work.

October 21's Muddiest Point

In the HTML page, the elements – and, in conjunction, the tags and attributes – all produce “permanent” effects that can only be changed by the creator in the HTML page, i.e. tags <b>…</b> bolds text and <body bg color = “green”> makes the background color perpetually green. Are these “static” elements the only kinds, though? Can there be elements coded to change on their own initiative or allow users to make changes themselves, such as writing and submitting comments?

Week 9 Readings

Articles

CSS Tutorial. (n.d.). w3schools.com. Retrieved from http://www.w3schools.com/css/

             The CSS Tutorial (n.d.) offers interesting details on CSS. One such point is the origins of CSS. According to the Tutorial, when developers added tags such as <font> and color attributes to the HTML 3.2 specification, the process of developing large web sites became longer and more expensive for web developers to complete. As such, the World Wide Web Consortium (W3C) constructed CSS so that, in HTML 4.0, a user can remove the formatting from HTML documents and store them in a separate CSS file (under Introduction, “Styles Solved a Big Problem”). In effect, then, the CSS was developed as a solution to an earlier problem – revealing how software and digital technologies evolved through trial and mishap.

            Another interesting detail was how a person could insert CSS into their work. The Tutorial (n.d.) lists three ways to do so: 1) an external style sheet, which changes the appearance of the Web site by changing one file (under CSS How To…, “External Style Sheet”); 2) an internal style sheet, used for single documents which have a unique style (ibid., “Internal Style Sheet”); and 3) inline styles, which mixes content with presentation (ibid., “Inline Styles). Such categories imply organization to the CSS’s development as well as the different manners in which CSS affects visual elements. A user can use CSS for more focused projects; no one has to stick to manipulating the presentation of a whole website when she or he really needs to differentiate individual pages from each other, for example.

 

CSS Tutorial: Starting with HTML + CSS. (n.d.) W3C. Retrieved from http://www.w3.org/Style/Examples/011/firstcss

             The “CSS Tutorial: Starting with HTML + CSS” (n.d.) covers some details that I’m unfamiliar with. For example, in the second “warning” for Step 1, it notes how the “ul” elements represent a list with one hyperlink per item, serving as the “site navigation menu,” while the “hl” and “p” elements “form the unique content of this page” (CSS Tutorial, n.d., under Step 1: The HTML). I found such “warnings” to be fascinating; they elaborate and build on the basic information of the Tutorial and introduce new ideas of using HTML. In the case of the example I gave, I am now curious at what “unique content” the “ul” and “p” elements produce and want to try that out.

            I particularly liked the Tutorial’s approach to colors. Step 2 covers the basics, teaching how to add color using the <style> elements – specifically <style type=“text/css”> and elaborating with how to set the colors for the text and background of the body (CSS Tutorial, n.d., under Step 2: Adding Some Colors). I love adding variation to my work when I can, experimenting with colors, type fonts, and the like, so I will need to investigate this when working with HTML. Similarly, the analysis on link colors under Step 5 was most interesting. I am familiar with the standard for having links to pages I haven’t visited remain blue while those which I have clicked becomes purple (ibid., under Step 5: Styling Links). However, I am now curious of why this is the standard. Having a consistent color-coordination is beneficial for the Web overall, allowing fewer confusions for newcomers without varying the colors. But why blue and purple? Why not some other colors, like green and red? Were the colors chosen randomly, or was thought put into it or does it correspond to a cultural norm? I really want to experiment with this, see if anyone would actually react if I changed the colors.

 

Lie, H.W. and B. Bos. (1999). Chapter 2 in Cascading Style Sheets, Designing for the Web. Boston: Addison-Wesley.

             After reading the Chapter, I found that H.W. Lie and B. Bos (1999) provided interest notes using organic metaphors. For example, their “anatomy” of rules and declarations. Each are made up of two parts – the rule consisting of the selector [the link between HTML documents and the style] and declaration [determines the effect of the rule] (Lie and Bos, 1999, under “Rules and Style Sheets,” “Anatomy of a rule”) and the declaration made up of properties [the quality] and value [specifies the type of quality] (ibid., “Anatomy of a declaration”). Each are interlinked, the declaration and all of its components contributing to the overall form of the rule. One part cannot exist with the other, or otherwise the rule as a whole fails. This is almost true for the human body; although the body can continue living without both kidneys, for example, overall it needs most of its organs intact to function fully as a living being. Viewing the anatomy of the rule like this emphasizes both its limitations and complexities in CSS.

            Another organic-like feature involves formatting documents in CSS as tree-structures. Lie and Bos suggest this course to emphasize the “inheritance” factor of the elements; “through inheritance, CSS property values set on one element will be transferred down the tree to its descendants” (Lies and Bos, 1999, under “Tree Structures and Inheritance”) but sometimes elements override others in the “children” (ibid., under “Overriding Inheritance”) or cannot be inherited (ibid., under “Properties that don’t inherit”). As such, the organic-metaphor allows users to understand CSS better. Most American public high schools teach the basics on genes and genealogy in biology courses, so theoretically a good number of people understand the basic idea of the transference of genes, and if not, most people are familiar with how family trees work. Users would be familiar with the logistics; thus, applied to the CSS, they can make the leap between metaphor and reality and be able to understand how CSS works.
            By emphasizing the organic metaphors, Lie and Bos almost imply that CCS documents are almost alive. They have “organs” which determine whether they live fully or not or how well they accomplish basic functions. They have elements that can be passed on to others “genetically.” This is an interesting method for them to use. They could be doing it accidently, for poetic reasons, to make their concepts more relatable, or to make a point on its complexity.

October 15's Muddiest Point

Different groups of people manage the Internet, such as the Internet Society (ISOC) and the Regional Internet Registries. Who do they answer to? Who or what determines the standards and policies they go by in overseeing the Internet? Or are they their own organizations, creating their own guidelines?

Week 8 Readings

Articles

“HTML Tutorial.” (n.d.). W3Schools. Retrieved from http://www.w3schools.com/HTML/

Overall, the document “HTML Tutorial” (n.d.) provided straightforward information on using HTML. A lot of it was new and unfamiliar. For example, under the chapter “HTML Editors,” the tutorial recommends different HTML editors for editing HTML – even going so far as to suggest that utilizing a basic text editor would help new users learn about HTML (“HTML Tutorial,” n.d., under “HTML Editors”). I did not know that such editors existed or that anyone would need it. In retrospect, though, it would make writing HTML more quick and efficient. I do wonder if their claim would work, however. It would depend on the user; some people can learn more easily with firsthand experience while others might need a more human guide in learning HTML.

There were some parts, though, I want to know more details about. In the introduction, the document states that HTML tags and HTML elements usually describe the same things, “but strictly speaking, an HTML element is everything between the start tag and the end tag, including the tags” (“HTML Tutorial,” n.d., under “Introduction”). Usually with the phrase “but strictly speaking,” a person means an opposite idea; in this case, it implies that although the tags and elements are used in the same way, they aren’t the same nor act in the same way. What’s confusing me is what the difference is. The description above for HTML tags describe the exact same thing (ibid.). So is there a difference? Should there be a difference? Additionally, I understand the basic idea for why the tutorial recommends using lower case attributes/attribute values since they are case-sensitive (ibid., under “HTML Attributes”) but I feel like there is more to it than that. If I understood the logistics better, I probably would know why lower case is used instead of upper case – such knowledge would hopefully clear things up a little. But why one over the other? If both can theoretically work, then maybe including both can expand the list of attributes to encompass new kinds or maybe help organize the ones in existence.

 

“HTML Cheatsheet Guide.” (2008). Webmonkey.com. Retrieved from http://www.wired.com/images/multimedia/webmonkeycheatsheet_full.pdf

            The guide “HTML Cheatsheet Guide” (2008) seems like it would be suitable for a quick reference. It provides tags and their descriptions for a lot of the most basic HTML a person might have to do, such as creating a HTML document with <html></html> (“HTML Cheatsheet Guide, 2008, under “Basic Tags”) or forming new paragraphs with <p></p> (ibid., under “Formatting). I’ve never had to use HTML like this before, so I cannot say for sure if the guide covers all of the basic tags or elements a user would necessarily need. From what I can interpret, though, it accomplishes its goals.

            If I ever had to create a HTML document by using HTML tags, I would like to experiment with the tags offered. I would need to get the basics down first, but the later sections – “Forms,” Graphical Elements,” and “Links” – would prove a good basic challenge. What would be the most interesting to try is the tags for creating Submit buttons (“HTML Cheatsheet Guide, 2008, under “Forms”) and adding images and their descriptions (ibid., under “Graphical Elements). The former seems a little more complicated than the other more straight-forward tags provided and the later would be fun to learn, especially since it would be helpful in the future to have an option in adding pictures to a document.

 

Pratter, F. E. (2011). “Introduction to HTML,” Chapter 2 of Web Development with SAS by Example. Retrieved from http://books.google.com/books?id=GQxv8xaIPFYC&printsec=frontcover&dq=inauthor:%22Frederick+E.+Pratter%22&hl=en&sa=X&ei=Mr9eUtnXEdSp4APItICACQ&ved=0CDoQ6AEwAg#v=onepage&q&f=false

            Reading this chapter helped answer some of my questions that I posed in the “HTML Tutorial.” For example, concerning lower vs upper case, F. E. Pratter (2011) notes that HTML 4.0 tags aren’t case sensitive but standard requires lower case (20). While this does not answer why lower case is preferred, it does elaborate on the background for my questions. However, it disagrees somewhat with the other readings. Apparently professional Web developers prefer to write HTML from its roots by employing text editors such as Notepad or KEDIT (Pratter, 2011, 16) – this questions somewhat the recommendation of “HTML Tutorial” that a basic editor would help beginners learn HTML (“HTML Tutorial,” n.d., under “HTML Editors”). Based on the context, they might be both wrong and right; some text editors would be basic enough for a novice to use and learn from, while there are more advanced versions for the professionals. It seems kind of strange that Pratter does not acknowledge the types of editors available based on expertise, or categorize them by some sort of evaluation. In this regard, the “HTML Tutorial” at least implies a difference even though it does not state it explicitly. This might have to do with the type of audiences they each target; both introduce users to HTML, but whereas the “HTML Tutorial” seems more like shorthand notes – noting differences and steps – the other is focused on explanations.

 

Goans, D., G. Leach, and T. M. Vogel. (2006). “Beyond HTML: Developing and re-imagining library web guides in a content management system.” Library Hi Tech 24(1): 29-53. DOI:10.1108/0737883061065209.

            The article overall provides a good analysis of web guides. In particular, D. Goans and his fellow writers’ (2006) look at what content is in a CMS was interesting. They note that “content” consists of a broad spectrum of forms depending on the organization, usually including resource links, webpages, image files, PDFs, PowerPoint presentations, and Word documents (Goans, Leach, and Vogel, 2006, 31-2). As such, there is no standard to what “content” is. It can include a wide variety of types of information as long as it is part of the CMS. Additionally, the content itself “is disconnected from the layout and design elements of the page” (ibid., 31). It makes sense; the content is the information itself and permanent while the layout and design elements can change. However, this can’t be entirely true. While the two can be separate, the content and layout and design elements do depend on each other to transfer knowledge. Layout and design elements also determine the appearance of the content, influencing how a user interprets the information, so the two are interconnected.

            Reading the article also offers a inside look into the development and consideration of web guides, which was informative. For example, the explanation of how they decided on the solutions to their problem – whether through commercial software such as Dreamweaver (Goans, Leach, and Vogel, 2006, 33), open source web site systems or “Frankensteining” products together (ibid., 34), or introducing an in-house web development project (ibid., 34) – supplied not only information on what options are out there for institutions in similar situations, but also gives an idea of how library management works, evaluating and determining options as a group.