Author: gincley.b

This class, particularly with the focus on genre, has reframed the way I look at and think about writing. Namely, I am more aware of the dynamic that exists between different written items, not that I didn’t know that different genres were connected or related or in response to one another before, but it is more clearly evident now. Rather than a subconscious acknowledgement type of awareness, this relationship is now at the forefront of my understanding of writing. Overall, this class has helped elucidate the less-apparent aspects of writing, both in terms of the rhetorical RACE constituents, as well as the process of uptake and genre interaction. I now see myself explicitly breaking down the rhetorical situation of what I am planning to write before I write it with this new conscious awareness.

While writing in XML was certainly a different writing process/experience, and it served to make rhetorical or content elements very explicit, it’s use was a bit of a double-edged sword in that it inherently pigeon-holed writing into predefined boxes for text to be deposited in and made the writing process a little more tedious. The use of schemas themselves were at times very helpful when following a predefined template, especially when writing something as established as a cover letter, ensuring that no important elements were forgotten or missed, and the proper structure was maintained. The process of creating a schema itself was a great way to understand and break down a genre into its basic constituents and structure, though the entire process itself wasn’t entirely efficient if it were to be replicated with every writing situation in the future (spending a week researching and breaking down a genre to write one piece for). While this process would be very helpful for breaking down a genre that is expected to be used often in the future (such as an actual blogger who creates new content every week seeking to standardize their unique style/structure/flow), it’s a bit cumbersome to use on a single instance. Ultimately, if people were to create a “schema” of sorts to define the conventions of a genre and make the results of their work open-source or publicly shared, it could serve as a useful tool for others to use and construct their own instances, though the mileage will vary depending on how static and established the specific genre is (it would be useful to publish this for a cover letter, less so a science blog). Though templates/examples/breakdowns do exist in the wider world, this specific approach contends to be equally or perhaps more useful for genre newcomers. On a side note, I had no trouble using any of the software we used in class, though I admittedly had experience with WordPress, XML, and GitHub coming into the course, so I was familiar.

In the course, what I found to be the most helpful were the class and group discussions about constructing schema. I found it most interesting how different people could have different conceptions and ideas for the same genre, for example. The ensuing discussion about either how to construct the schema, feedback about a schema constructed by others, or peer comparison between how different people used a flexible schema in some very different ways (science blogs), proved to be the highlights of the course for me. To be completely honest, and perhaps my technical-focused education over the past few years is showing itself, but I found most of the class readings to be a bit dry, abstract, and heady, and was more interested in the summary/conclusions and following discussion of relevance to what we were doing in our writing processes than the actual writings themselves. I therefore really appreciated that the conclusions of the readings and the application of those conclusions to the writing were more critical to the discussions and grading of the course, rather than the literal content of the readings themselves (no reading quizzes, etc.).

Moving forward, I feel that the mindset created by this course is the most important take-away, and I hope to hold onto it for the rest of my academic and professional career. Explicitly thinking about RACE and uptake before beginning a written item is a highly useful way to frame the writing and make it that much more effective. If possible, I also look forward to taking this awareness to discussions with peers, whether they be reviews of already completed work, or when breaking down something that is yet to be written (such as a collaborative paper, etc.). This way of thinking seems to be a fundamental underpinning of a solid writing process, and should be applicable to some extent in all situations, even if it’s as little as a cognizant awareness of audience and uptake.

The template looks by and large unchanged, as most of the comments were regarding the template document itself and how it was arranged, and less about the entire schema as a separate entity. Based on the team design entry, it looks like the group was interested in removing the “specific topic” element, as it seemed redundant. By the end of the revision process of the elements used in the final version, it is true that the line between the specific element and the “technical principle” element became blurred, but the intention was to have the latter denote a broad concept, and the former to mark a narrow, field-specific piece of information, which appears to be ultimately maintained. Though we considered merging the two, this distinction seemed important enough to ultimately keep the elements separate.

The main concern was with the template/structure of the schema itself, which is not inherently intuitive to an outside user. Our group decided to forgo the creation of a true “template” document simply because we each ordered our elements and formulated our structures a little differently, so we didn’t want to create a template that artificially led users to follow one specific structure/style as opposed to others. What came as  a concern from the project 3 individuals, in that they created their documents separately as plain text and then took the schema and marked up their largely already finished work (in terms of content), actually reflected the process we in project 2 took. The way of executing the genre is in some ways backwards to how the other genres were structured, in which it was easier to take the schema and construct the piece directly from that. In the case of the blogs, it was almost by design that the schema was used to tweak an already created piece. The inherent issue with this, which the project 3 group brought up, was that it was difficult to construct the piece and adhere to the schema’s rules if you were not in the group that originally designed it, which in hindsight is perfectly valid. While the schema was meant to serve less as a crutch and more of a way of tagging an already formulated (physically or mentally) piece of writing, this ultimately proved to be somewhat challenging for newcomers to the project/genre.

To be more helpful in the future, I would be in favor of the creation of a template that served as a sample model rather than a list of the elements, but do warn of the potential for the perception that such a document might create artificial perceptual constraints on what is possible within the genre. Ultimately, I feel that in our effort to, by the end, make the schema as forgiving of individuality and as nonrestrictive as possible, we inadvertently created a schema that was perhaps too vague to easily follow.

I used the Cover Letter schema/template mostly as it was written originally, using it as an outline to structure the document, using all (or almost all?) of the elements. The schema served as a stable basis for the project, and I used the elements as prompts for content. In the body paragraphs, I wrote the content and then tagged it with the more minor elements, but in the rest of the document, the elements presented in the template served as prompts for which content I should put where. The schema itself felt highly appropriate for the situation, as it contained all of the relevant information and followed examples found online/other sources, and maintained the structure and brevity of the genre itself. Some elements, such as the intent, reason, and proposition, were incredibly helpful, as I would not have known to delineate those as three separate items. Most of the critique and feedback during the peer review, in both directions, was more focused on content, as both followed the schema rules themselves perfectly. We had similar styles of markup, and overall in this relatively cut-and-dry genre, there isn’t a lot of room for creativity. In terms of specificity, the background section is slightly broad, as to what constitutes personal vs. school vs. work in some specific situations such as volunteer research work (which is in a sense all three), though ultimately it felt okay to leave that up to the writer to decide where something like that would fit in terms of balance and flow.

Overall, this schema is radically different from my WP2 schema, in that it feels like there is much more inherent structure, and though the order of the background content is flexible, overall the genre/schema itself felt much more of an outline to fill in rather than a flowing journey almost fully up to the discretion of the writer. It was a nice change of pace in some ways. Ultimately, I feel this genre model/schema gets the job done. More elements could be added for greater specificity for the background section, but that would also complicate and clutter that section perhaps unnecessarily with the extra tags. I am content leaving the model largely as-is moving forward.

The schema was overall designed to provide some structure, but leave most of the element use and order up to the discretion of the author. In this way, the schema provided “guidelines” or a loose framework, akin to perhaps a rubric, as opposed to serving as a template meant for blanks to be filled with content. I personally found that the schema provided just the right balance for structure and style, in part because I had influenced the generation of the schema based on my own mental interpretation of the genre, and then followed that style/structure in my composition. Other group members found some elements a bit constraining, so we added more flexibility, merging two specific elements and making some rigid elements global. Much of this originally came directly from the research, in which various forms of the genre exist, but it was up to our group to decide where to draw the line between what constituted our genre, and what was something else. In accounting for these similar but slightly different examples, the resulting schema was made to consist of an array of global elements that could be used at the author’s discretion.

Overall, the writing in XML is pretty natural, and the schema we developed was created with the intention of not being too tedious to complete correctly. While it takes more effort to break down sentences/paragraphs into discrete elements, as opposed to simply writing them without markup, the process makes the entire situation more explicit and confers greater understanding of the writing that is taking place.

I found both the group and individual aspects great for developing my understanding of writing. It was important to work in a group to develop the schema, to allow for different ideas and perspectives to collectively decide what would universally make the most sense, as opposed to being based solely on one person’s perspective of what they believe the genre entails. With our genre in particular, the individual component was interesting in that while the composition process itself reinforced the understanding of how the genre behaves, comparing the end products of each individual demonstrated how individual authors with the same genre and rulebook can create pieces that are remarkably diverse. I found it most interesting to see how the compositions were similar, and how they were different, and through that discussion and comparison after the fact, new perspectives were gained (such as from one person’s use of a certain element, or another person’s flow, etc.).

If I were to change anything, I might increase the group size (we only had 4 members, it may have been interesting to have even more perspectives with 5 or 6, though reaching a consensus might have been more difficult). Overall, I feel this project went very well, and like how it is interfacing with WP3 in that individuals outside the original group will be electing to compose a piece of another genre. It will be interesting from the perspective of the process itself to see the outcomes of others’ work, what thoughts they have about the schema and what changes they would make, etc.

The “Cover Letter” genre jumps out as a simple yet practical genre to study closer. I have not yet had to write a cover letter for a job application so far, but will almost certainly need to later this Fall, or a latest, before I graduate. In situations where I find myself applying for a job, as positions get more competitive, a cover letter would be necessary to serve as the bridge between a resume and a potential interview. In such a situation, the audience would be the hiring manager of a company or organization I am interested in working at, and the desired uptake would be to demonstrate both a level of interest and competency in the position available, enough to warrant the scheduling of an interview and therefore improve my chances of being accepted at the position.

The examples and genre template provide a structured, thorough demonstration of a standard cover letter expected in the industry. They outline the order of required/recommended components, and provide a stable structure to ensure no important components are missed, thereby increasing the credibility of the document. In the template itself, there appear to be some elements that are embedded in others, and it is unclear if they can only go in those elements, or if that is just a suggestion, and they can go anywhere in the overarching structural element. What might have been useful, at least from my group’s perspective, might have been to make those sub-elements “global” elements and specify them as such in the template (they might be specified this way in documentation that I can’t as of yet see/find). This way, it would be clear that they can be used in any place where they appropriately fit, based on the requirements and discretion of the author.

Overall, the tone is somewhat rigid/distant, but hopeful. This makes sense, as the author is writing to someone they presumably have never met before, and are attempting to prove their value enough to be brought in for an interview. In such a short document, it feels difficult to express individual personality while not coming across too strong, and maintaining the structure and brevity of the genre itself. The content appears to highlight the key/most relevant items of the resume, and describe them in slightly more detail than the resume can. Before I undertake this genre on my own, I would need to do some preliminary research on other examples of the genre, perhaps found through Northeastern’s resource links, and find a realistic job posting that I can see myself legitimately applying to in the near future to make this exercise the most effective and relevant to my own experience.

After establishing the schema over the course of several days, I used my mental framework of the schema layout while drafting an initial version of a science blog post in another medium, and then copied the text into XML and appropriately tagged and grouped the various structural and rhetorical elements. The schema overall felt appropriate for the situation, and provided the resources in the form of elements to explicitly mark up the body of text the post was built from. The schema itself did not exactly feel constraining, and served as a structural scaffolding to build the post around. In some cases, nuances in the schema structure itself (like the schema disallowing embedding of some elements within others) proved slightly annoying, but were easy to work around. Overall the ordered flow provided a good basis for walking through the genre for the first time, ensuring that the flowing process of the answer/explanation happened in the right order. Additionally, the flexibility inherent in the use of global elements provided a great toolbox of flexible elements to be used at the writer’s discretion.

I felt that my partner’s composition looked very similar to mine, though the content and exact style was slightly different. Looking at his schema and cases where oXygen indicated schema violations, it might be worth re-examining the ability to embed certain elements within others, as there were some instances where the schema was expecting an end tag where an element was embedded within another. This seemed to occur when one structural element was embedded within another.

The schema created in small groups felt more personal than the one created as a whole class, in that it was a tighter fit to my mental representation in the genre. This may be a result of working on the genre for a longer period of time and having a more direct impact on the final schema model, but overall I felt that the schema fit as much to my intentions for the composition as the composition fit the schema. In both cases there were elements or attributes that were not used, but in the case of the second writing project, those elements were made deliberately optional with the intention of only being used as the situation demanded, and were not as common in the genre examples that I personally researched. As a result, I was less prone to using them anyway.

I would be interested in making the “misconceptions” element a global one, removing the restriction of using it as a structural element to allow for flows/styles different from my own mental genre formula.

Typically, the genre of scientific blogging is preceded either by scientific publications, or scientific texts/textbooks. This genre takes up these genres by extracting the key points and principles presented, and attempts to translate them so that they are more accessible and easier taken up by people without a hardcore scientific background. This genre uses preceding genres for their content, and rely on the author to effectively use analogy to convert the material. Overall, the technical nature of the scientific writing is reflected in this genre, as the scientific content, and at times, depth of explanation, is considerable. Also, just as scientific writings are meant to share findings with a broader community, this goal is shared by the genre of scientific blogging.

Genres that follow are usually end-user thought and interactions with others in the forms of conversations. The genre allows individuals the resources to turn around and explain the concepts in similar ways to others, which is particularly effective for people in teaching disciplines. Teachers/tutors/instructors can use the genre as a more accessible point of entry for their students/pupils, taking up the genre and generating discussions and other genres of communication. The desired uptake of the genre is for the users to reach a level of understanding about a topic that they may not have had a stable understanding of, allowing them a fundamental understanding of the science going on. Alternatively, the genre also seeks to extend new perspectives to users, to allow them a new frame of reference or way of looking at a certain phenomenon. Ultimately, the goal is to explain in such a way that the users of the genre can turn around and explain it to someone else in simple terms that both understand.

The desired uptake is reflected in the way the information is presented, through use of simpler analogies, where the hope is that a simple/fundamental understanding of the science at play is achieved by the reader.

Focusing on the genre of scientific blogging, particularly the subgenre that takes concepts and questions and uses analogy, humor, common vernacular, and drawings/animations to explain concepts, this particular body of work serves as an intermediary between the public at large and more technical scientific documents and publications. The genre is by definition designed to meet the needs of wider consumption, as it is difficult even for scientifically minded individuals to extract the takeaways from many publications if they are not trained in deconstructing them. Typically, it takes a particular type of person to be able to compose this genre, as they need to be able to read and digest technical documents such as scientific writings (publications, books, etc.) and create analogies and images that are easy to understand, thus “simplifying” the concepts, taking care not to loose the main ideas from the work in the process. Those who read and use this genre are those who have questions or wonder about scientific principles, but find the primary sources difficult to break apart and draw conclusions from, either from lack of technical training, or lack of time/energy to do so.

The genre is in part by definition a response to the relative inaccessibility of the more technical scientific genres. Most often, such documents are written by scientists for scientists, and are often field-specific, meaning it’s difficult for a materials scientist to easily break apart a molecular biology publication due not only to the specific jargon of the science involved, but also the formatting, flow, and structure/layout of the publications. The genre in question is designed to take findings or explanations and put them in terms that every human can comprehend, regardless of their field, profession, or level of experience (more or less), arising from the demand for a more easily digested intermediary between the public at large and technical documents.

This genre can be thought of in the Genre Repertoires perspective, in which it would be important to examine or be familiar with the foregrounded genres of official scientific documentation, and understanding the communitarian action of the genre itself, in which members of the community with particular fields of expertise explain their areas of interest to others in terms they can understand. Over time, the demand for the genre creates some individuals who devote their times to specializing in multiple fields, but the root of the genre comes from the community as a whole, sprouting from individuals who span the gap between technical science and public. It would also be interesting to examine if there is overlap and interplay, wherein, in response to this genre, if any scientific documentation take from this model and summarize their conclusions in a similar fashion in the original publications or in supporting documentation.

Looking at Oliver’s Project 1 document, and starting with the problem statement, it is interesting that the statement, and largely the document itself, is centered more around the problem and less around the discipline, a contrast to my approach. To note, Oliver did not explicitly mention his discipline in the problem statement itself, but rather colored the story of the problem. Extracting from his annotations, it appears that his selected discipline is electrical and computer engineering (or related), though nowhere is this made glaringly specific. This more subtle approach is an interesting contrast to mine.

When looking at the structure of citations, it appears that Oliver had made the citations based off of the schema we had determined, as evidenced by the forward-reading author names and flow/structure of the citations themselves of [taggable materials] [everything else, if available]. In contrast, I had taken the direct citation from the sources themselves (either from the publication source or scientific publication indexing/citing software), pasted it into XML, and then worked around it to put each item into tags. This difference in approaches is interesting, and likely came from a minimum-required-effort perspective: for me, long citations were available already formatted, and it was easier to fit tags around them than match the precision of the citation style typing on my own; for him, sources seemed to have come mainly from the web, and therefore citations would have to be constructed manually anyway.

As for the annotations, Oliver seems to have made an effort to include every tag whenever possible, whereas I had omitted some tags and largely kept to a 4-element annotation, while he maintained a 6-element pattern. Both of us appeared to have decided on which element was being used first, wrote the text for that element, closed it, and then began the next element. Neither of us had text that existed outside of elements. While my elements usually contained two sentences each, Oliver seems to have held a pretty strict 1-sentence-per-element regime, another interesting interpretation of the schema structure.

After viewing his structure, I would consider taking a closer look at my tagging to see if I could have broken some elements into two smaller ones, as Oliver had done.

Aspects of the assignment, particularly the annotation section, felt more explicit, structured, and guided when composed in XML as opposed to written straight into a word processor. I composed all of the writing in oXygen itself, and as a result my annotations were strongly based on the element structure, including the relevant tags and what they were meant to contain. While it felt somewhat tedious to complete each element individually to meet the requirements, I did find that the structure made the requirements of the assignment specific, and I felt I had little to do once I had completed each of the required elements.

The citation portion of the assignment felt more tedious, and although in XML it allowed for each component to be more explicit, I felt it to almost be more work than it was worth to surround each component of the citation in a separate element, especially considering the appearance of the final product is no different from the directly copied version of the citation from the source material. It also felt tedious to specifically label each component when, at least from my perspective, the component identities are self-evident (tagging the first [last name, initial] as <author n=”1″> felt, to some degree, redundantly obvious. In situations where citing journal publications that had so many authors that the citation format itself lists the intermediary supporting authors as […], I opted to only specify the primary author with an n=”” attribute, and lumped the remaining 7+ authors into a separate <author> element with nonspecified [n] attribute simply in the interest of time. In this respect, I feel that the XML format of the assignment in a way broke down, in that it, if carried out in exact accordance with the schema, an excessively redundant amount of input would have been required (to number each author individually).

Ultimately, I felt that the process of writing the assignment in XML was overall smooth and simple, and added a layer of explicit structure that lent itself to automatically fulfilling the requirements of the assignment. Moving forward, I would have no problem using oXygen to continue working on future assignments. However, in the case of sources with an unreasonable number of cited authors, the system itself began to break down. If I were to change the schema, I would explicitly restructure the attribute types for author to be “primary” and “supporting” instead of numbering.

As I understand it, the social action involved in writing an annotated bibliography is that it opens up a connection between source and citer, in that the citer highlights the key takeaways from the source and creates a document of sources that are all related in some way, sources that previously may not have been linked before. This allows for a network to develop between these sources for the authors and/or users of the annotated bibliography to draw connections between the different cited works, and as a result, generate new perspectives and ideas relating to the core/central problem or challenge.

Within the broader scope of engineering, I aim to take my skills into biological engineering, particularly neural engineering. Currently, in the subfield of brain-machine interfacing, there is a gap between what is theoretically possible, and what has been physically achieved. There are cases of successful animal experiments and some clinical successes, but by and large it is a challenge to decode neuronal signals into definitively understood messages, and to encode computer-originating commands into neural signals. Much of the work takes place in an academic research setting, and progress is documented in scientific journal publications.

One avenue of study and human application in this discipline is neuroprosthetics, or artificial devices that are used to repair, replace, or augment biological function, often as part of a therapy for those suffering from an illness or disability. Simple device examples include cochlear implants that repair hearing function, or prosthetic limbs that have basic functions controllable by the individual’s intentions of movement. Though the discipline has come a long way in a short period of time, there are still many hurdles to cross, including reducing device invasiveness and power consumption, improving range of functions devices are able to restore function to, and integrating devices into biological materials to convert “cyborg”-type treatments into more biologically natural alternatives.

Those struggling with neural tissue damage or loss of sensory/motor function number in the dozens of millions worldwide, suffering from diseases and disorders including Alzheimer’s, Huntington’s, Parkinson’s, traumatic brain injury, conditions of partial or total paralysis or limb loss, a number of speech deficits, natural decline of sensory and cognitive function with age, among many others. Those working in this medical engineering discipline strive to restore normal function to people suffering from a neural-related deficit, primarily through experimental techniques in academic research and clinical research settings. Academic research investigates novel techniques, technologies, and therapies, and clinical research investigates their efficacy with real patients. Through these careful investigations, often funded by large research foundations like the National Science Foundation or the National Institutes of Health and clinically regulated by the FDA, engineers and scientists attempt to find and develop practical treatments.

Beyond restoration of function, organizations like DARPA fund research into neural augmentation, often for military applications, that allow direct interfacing between tactical technologies and personnel (usually military). One such application of the technology is integrating an individual’s neuromotor commands with the power system for exoskeletal/mechanical suits that augment the strength and weight-bearing capabilities of military personnel, thus allowing for natural mental control of the suits. The most cutting-edge work in this sector of the discipline is often rarely seen in detail by the public eye due to the classified nature of the technology, but public information is published similarly in scientific journals.

Ultimately, neural engineering is a new and rapidly developing industry with medical, military, and eventually, consumer quality-of-life applications, for which the possibilities for its use are nearly endless (restoration of function, sensory augmentation, information transfer/storage, cognitive enhancement, direct neural interfacing with devices and other people, etc.).