Author: scott.o

A variety of changes were made to the documentation of the schema’s definitions. Some rewording might have been inadvertently done, during the process of copying and pasting, however more intentional changes were made in order to make the structure of the schema more evident (Granted these changes were all made in the template file, so I do not believe a direct adaptation to the schema is possible.). The chief decision regarding documentation was to condense all necessary information to create a draft of the schema into a single document (template file). By structuring the documentation in a more consistent style, I believe I was able to make it more clear to a reader what was being asked of them in each section, and was caused by my initial displeasure with parsing together how to approach the schema by looking directly at schema documentation, in addition to referencing the template document.  Other small changes like correcting minor errors (e.g. the ‘cost’ page not appearing on the template, some incomplete definitions), or fleshing out points to make them more clear were also made.

The proposed changes to the schema are as follows :

prelim_ana – I felt the goals of this section were obscure with respect to those found in the ’sccs_crt’ section. To try and better communicate the nuanced differences, I renamed the attribute to ‘prelim_ana’ from ‘prelim_req_ana’. It was not clear to me what ‘req’ was referring to. I also added important definitional specifications that highlight the differences between these two attributes.

exec_sum – For the exec_sum page, I would add the following tags that must be written in order : background, report_purpose, approach, key_findings. These (along with their informational definitions) provide the writer with a better idea of what a representation of an executive summary should look like. This was inspired by the fact I had no experience with executive summaries, and when referencing the individual writings of group 2 and correlating them with what I found online, I found an undefined range of expositional tone setting to concisely informational.

fsb –  I changed the <fsb_hlgt> element’s ‘suits’ attribute type name to ‘lgl’. Not only do I believe that this name has a more obvious meaning to it, but it also matches the naming of the legal type attribute for the ‘cost’ page.

sscs_crt – I added four attribute types for the <req_sect> element. These were, ‘technl’, ‘tmfrm’, ‘socl’, ‘other’. I believe these attribute types lend a better understanding to the concrete demands that are being put forth, helping to distinguish its purpose from ‘prelim_ana’.

fnc : I removed the ‘exp’ type attribute from this section. It seems there is redundancy here with respect to this page and the ‘cost’ page.

conc : I removed the ‘sum’ tag. It seems to me that the conclusion section is better situated as being entirely a summary section, rather than a set of sentences toward the end of the section. This was also informed by examples I found online.

Three last structural notes, it seems that it would make more sense in the genre if only one of each page type were allowed per page; secondly, the ’n’ tag specified in sections other than ’tbl_contents’ don’t seem to have much importance, and I believe can be removed without jeopardizing the genre model; thirdly, I found the enforced ordering of the pages to seem somewhat arbitrary. It seems the fastest way to be informed on the correct order by generating errors by placing pages in the incorrect order. Although changes could be made so that the schema more directly represents the genre, I do not believe that either change would greatly have changed my writing process.

As I was finishing WP2 I had the realization that it hadn’t been the schema that drove my writing process, but the writing process that drove the schema. I believe this was understandable for the first portion of the writing assignment — at which point we were evaluating our schema and making changes in accordance with how an example of the genre might look — however during the rewrite phase I think it might have been more appropriate for me to consider other approaches to my structure.

While I’m not immediately convinced that there exists an obvious way in which to improve my approach in relation to our final schema, this thought was highlighted during my final round of edits. I found that the changes we made for the ‘specific_topic’ and ‘explanation’ tags caused slight issues due to their ordering requirements with respect to the ‘technical_principle’ tag. Due to list type nature of my ‘answer’ section, the ‘answer’ section does not flow in a natural way, but it is intentionally divided therefore making the section feel less “spacious” than if I were to have it undivided. It felt natural that each of the topics within the list deserved their own ‘specific_topic’, however this necessitated that I find a way to include ‘technical_detail’ in a limited amount of space before the start of the ‘specific_topic’ list.

Although I wouldn’t claim that I actively sought out and applied analysis tools brought forth during the required readings, if there were one that might apply to my approach it would be the discourse community. The nature of blogs puts the community appeal, tone and discourse in the front seat, making you very aware of your audience while writing the blog.

In conjunction with the class material, I felt the group project offered a very useful mechanism for developing an understanding of the genre. While there were benefits of collaborative group effort in dividing workload to cover many different sources from a variety of mediums — the chief source of understanding for myself derived from a sense of added responsibility when working within a group. I find I’m much more comfortable with letting myself down than letting others down, and a consequence of this is that in group projects I do my best to be checked in and contributing at all times.

I really appreciated how open the prompt for the assignment was. By allowing us to choose a topic of interest, I found myself much more engaged in the material. Twofold, it allowed me to choose topics that I felt would benefit me outside of the class, increasing my investment in not only the structure and details of rhetoric, but in the substance as well.

If I *had* to change any part of this project, I think I might integrate the points made in the readings into our individual write ups. This could be something like a section of XML common in all projects covering topics, like <discourse_community>, <audience>, etc. These topics are covered in the design entries as well, however a direct analysis of our specific projects would be helpful in cementing the ideas.

During the presentation for the feasibility report, Seth mentioned that the topic of feasibility reports was one which one of his computer science professors regular brought up. Due to my own interest in the computer science field, and probably party due to being a victim of ‘imposter syndrome’, this comment marked the moment when I decided it is high time Oliver Scott gains some experience with feasibility reports. Although the cover letter is another genre that I would undoubtedly find myself replicating outside of class, I believe this is a genre with a large number of samples on the internet, and one that I feel I have somewhat of an understanding of already.

Feasibility reports, as the name suggests, are a vital topic for those working in the technical professions — especially those which are project based. During my co-op experience working at a tech startup, the rate at which the management team drops old projects and seeks out new ones provides the perfect scenario for feasibility reports. Being able to understand what is required to complete a project, and forecast the relevant details on how to complete it is vital before embarking on a new project. I see the scenario going as such: 1. Manager notifies me of a design goal being considered. 2. Research the design goal. 3. Report back to the manager with my feasibility report.

Reading the template file not only conveys what the feasibility report is, and the structure of it, but in this particular instance it is also clear that the group in question kept in mind a high priority for strict organization and modularity in their schema.

It wasn’t clear to me from the template file how various attributes would be applied for certain sections (for example, ‘rss’ in ‘pre_req_ana’) however it seems that there is documentation within the class schema file, so with that in mind I don’t believe I should run into any issues.

The tone is informed and professional for the feasibility reports I skimmed. I don’t believe this will be too difficult to replicate, however I will need to do some research in determining how to approximate the timeline for the project.

I found the greatest strength of our schema to be its flexibility. In thinking about how to structure my document, it had the benefit of helping me to differentiate the background and answer as two separate entities, but otherwise it allowed for a freedom of form I think is inherent to blogs. Additionally I weighed heavily on the ‘important points’ and ‘roadmap’ tags of our schema, allowing me to think about all needed explanations in a digestible manner, however after reading Tammy’s submission, it was clear that the way I used these tools was not the only way to do so.

One of the few circumstances I found that could benefit from broadening the genre was the ‘scentific_principle’ tag, the description of which feels perhaps too clinical. I think a ‘technical_principal’ might broaden the use of it in a way that explicitly scientific topics in addition to technical topics might be discussed equally. This same point might be said for the ‘fundamental_science_involved’. In both of these instances the documentation would need alteration as well. I think the documentation could also find heuristic benefits if the examples used in sequential element descriptions were related to each other so a user could get an idea of how the topics might be used in conjunction with each other with regard to a particular prompt.

In addition to the flexibility of this schema, I think the majority of my satisfaction was derived from having a clear understanding of the implications of each discussed element as we were creating them. This can be attributed to a) having already gone through the process of developing a schema earlier in class, and b) being in a small group allows for greater command of the final decisions, so less need to make concessions keeps a uniform vision in tact.

Although I felt very content when writing my entry, I am curious if other group members see the way in which we approached elements as being the effect of flexibility, or that of us not having a clear understanding of the schema. From looking at the other members (aside from the broad outline of the schema), we leverage elements as they fit to our style, rather than fitting our style to the elements. I see this as being an inherent part of the blogging domain, however perhaps other members will want to instantiate a more regimented approach before handing our schema off to another group.

There is no chicken-or-egg question when it comes to blog entries discussing complex topics, and the research that these entries are referencing. An acceptable definition is almost certainly workable that would state the genre of research as being antecedent to that of the blog entry. Although broader consequences of the research may be illuminated by the entries, the entries themselves give no attempt at adding to the research of the topic at hand. The genre of research doesn’t directly presuppose that it ought to be brought to the masses in layman’s terms, however there is an appreciable need for this translation in order to ease in the understanding of important issues for those who are affected by them but do not understand them.

Just as our genre would not exist without the theoretical existence of research on a specific topic, it would would lose importance if it detached itself from the direct instances — journals, reports, etc. — of this research. By providing both off hand references to names and projects in addition to direct citations, the views of the blogger are kept within the realm of reality and legitimized to the reader. These references fulfill the criteria for the first half of the definition of uptake, and the ability to translate them to high-school-readable levels and digestible analogies fulfills the latter half.

The explicit genres that might follow our genre would be those which exist on various social networking platforms. This is seen in links that allow the reader to subscribe to the blog, or share it on Twitter, Facebook, Instagram etc. Another avenue of interaction is a comment section present in most of these blogs. Not only does this help to spread the name of the blog to which the entry belongs to, but it also targets an audience which is most likely to be receptive to educating themselves on the topic (friends with similar interest, typically a younger demographic). I believe an implicit uptake of our genre is also to educate the reader so that they might make changes in their own lives or value systems, in addition to helping the reader to communicate the ideas they’ve read about to friends in their own life.

In our initial draft of our genre model we accounted for the explicit uptake of social media forwarding by including elements for this purpose. Ultimately we chose to remove the comment section and a few other existing uptake related elements as fabricating their existence seemed unimportant.

The genre my team is developing is of the translation of difficult topics from the complex to the vernacular. At a finer level, we are focusing not only on the blogging side of this realm, but more pointedly on those blogs which make a concerted effort to relate to, and entertain, the reader. This is accomplished by leveraging modularity of discussion, humor, analogies, images and a perhaps incidental use of first person.

The genre is akin to a veil being thrown over a swath of difficult to understand sources relating to a singular difficult to understand topic. If the author of the blog tailors the veil correctly, the sources that he/she relies upon to create the blog entry should be undetectable to the reader — instead leaving the impression that a trustworthy oaf who happens to be grounded on a particular topic is doing you the favor of telling you what they overheard two professors saying about it during a long elevator ride.

The benefit of a well executed example of this genre, is that it can spread with ease over the internet. Although in a sense sharing the entry on social media is transitively sharing the scientific papers and research that it is referencing, that of course is not the impression that is given off to the unsuspecting Facebook scroller.

In order to orchestrate this successfully formulated entry, the author must operate in a world in which he must act as a student when reading complex papers, be professional when interviewing experts, be relatable when detailing his/her conclusions, be sensitive to the efficacy of his/her style — making alterations accordingly, and wear any given number of other generic hats.

While the reading was a helpful reminder to view the generic elements with a more clinical eye, I found the dictating of genre analysis frameworks to be forcefully abstract. Perhaps considering the differences between the frameworks might have yielded a stronger and nonintuitive understanding of the purpose of each genre frameworks — and the benefits of each approach with relation to the others — I cannot shake the apathetic feelings of an engineer taking a writing course as to how much added insight can divulged by using the different frameworks listed.

During my most recent co-op, I worked as a Systems Engineer at a small Cambridge startup involved in the emerging field of carbon nanotube (CNT) production. A production machine with the price tag of a mansion in a place called something like ‘Quiet Rivera,’ and the appearance of a grunge rocker’s winnebago is at the center of the company’s undertakings.

Given the unexplored status of CNT production, the unique element of necessitating research with engineering is the defining aspect of working at N12. You have to be focused intently on what it is that you’ve been trained in — as you are likely the only one doing it — and yet sensitive to the demands of the other specialities so that motors spin fast so long as CNTs grow thick. If I had been asked a week ago as to the degree of interconnectedness of the mechanical engineers, computer engineers, electrical engineers and chemists, I would have no doubt have ranked it as high as the scale I was given allowed for.

After reading Leavy’s paper however, some now evident points were brought to light that display the potential for greater levels of interoperability, in addition to the realization that the workplace could even have been categorized as multidisciplinary by Leavy’s definition. In hindsight, although engineers worked alongside each other and chemists in a familiar and highly accommodating manner, a deep understanding of each other’s processes beyond observable properties was minimal amongst the majority of the team. Some engineers would certainly fit the bill for transdisciplinarity, however the general attitude is that only the chief engineers of each field should be able to transcend their discipline — and with their analysis other engineers could be delegated.

It’s difficult to imagine how this bridge might be mended without taking team members off of their projects of interest. Thinking back on N12 fills my head with only positive adjectives, and yet I still don’t think that I will step back into my role there upon graduating. Questions over how I will bend my degree toward hardware or software, where in the world I might locate myself to do so, and the dreaded question of if I can truly see myself being a lifetime engineer are still present. Luckily there is still some time to figure that out, and maybe broaden my specialties as I do so.

Ben Gincely uses the study of his field to approach a much broader, and transdisciplinary issue than my topic of automatic waste sorting. In investigating neural engineering, Gincely investigates an issue in not only a vitally applicable realm, but one in which further research is demanded. The nature of this topic seems to be reflected in the approach to his problem statement, which has a greater emphasis on providing the scientific context of neural engineering, than the societal context I provided in my own annotated bibliography.

The XML content of Gincely’s citations had a higher degree of complexity than my own. He leveraged the title ‘level’ attribute, in addition to providing untagged text.

Of note for the annotation content, Gincely opened each of his entries with more in-depth research on the people and institutions behind each source. Additionally he managed to maintain a smoother transitional effect between sections, aided by the choice of not forcing every element attribute variant into each entry. This is primarily seen in his forgoing of the summary ‘interpretation’ and relevance ‘value statement’ attributes.

Lastly of note on semantics: Whereas in my work I used inconsistent (and in some cases incomplete) citation styles, Gincely’s work was of more proper formatting. Unfortunately I hadn’t thought to look at the provided examples earlier on in the project, however in hindsight I should have corrected myself to fit a description closer to Gincley’s. Additionally, the flow of Gincely’s annotations provided for a more fluid reading experience, however I am unsure that I would have been able to accomplish the same without breaching the 200 word limit.

My immediate takeaways after completing the first assigned project are likely the intended ones. The strict structuring of XML provided an ideal means of making explicit the context and weight of each sentence. I began the project with an understanding of these implications however, they were made painfully more clear after rereading the project guidelines once completing my annotations.

As I had begun my project without the word count restrictions in mind, rereading the instructions necessitated cutting several sentences from each of my entries. Although such a realization tastes like sour lemonade when the alternative is going to bed, the process heightened my understanding for the economy of words. Tailoring the delivery of the annotations to fit these constraints without sacrificing meaning was an important, and dare I say, even a gratifying step in the writing process.

In hindsight I think the schema’s structure for source/author background could have had a more open definition. The running definition placed an emphasis on providing credibility for the source/author, that I believe was perhaps overstated. Attempting to both hone in on the chops of the source/author, in addition to giving a general idea of the goal of the paper — without treading into the summary section — felt somewhat unnecessary.

Another uncovered area is that there were no restrictions in place on mixing and matching different citations styles. During my project I (regrettably) used a mix of APA and IEEE. Although I didn’t think about consolidating all sources under a single citation style, I assume that there should be a homogenous method of citation, and mixing and matching wouldn’t be permitted. Or maybe I’m wrong about that, hope so!

Oxygen as a development suite seems to have all the nuts, bolts and autocomplete features I would want from any IDE. Organizing future projects using Oxygen seems like a fitting way to leverage XML to structure future writing assignments.

Engineering, almost by definition, has a penchant for providing extremely concrete tools without specifying any required circumstances for how these tools might be applied. An exact solution provided for inexact problems. Just as this is true to the other engineering disciplines, so is it for computer engineering.

Computer engineering can be loosely thought of as the bastardized combination of electrical engineering and computer science. While a more shallow depth of knowledge is required in both circuits and programming in the general sense, the exception is the higher degree of understanding of low level programming.

Low level programming has a wide swath of uses that allow for less flashy, however far more efficient applications. To illustrate this, a computer science major might program a calculator using Java (a high level programming language), whereas a computer engineer could (with a higher degree of difficulty and at greater cost) create the same calculator using an FPGA (field-programmable gate array) for noticeably faster calculations. In some situations however, the added efficiency and reliability are unnecessary. (For example, the calculator on an iPhone satisfies the speed and usability needed for the majority of daily mathematical calculations.).

Within the computer engineering world there exist a myriad of internal divisional tasks. Firmware allows electrical devices to function in raw capacities, drivers that allow these devices to communicate in an interpretable manner and communication regulation for networks. Although the principles of design and language will likely be consistent through these sub-fields, the tasks of these three engineering roles (Firmware Engineer, Computer Engineer, and Systems Engineer) will vary dramatically. Yet, as a nod to the diverse applicability of engineering, the end application of a Firmware Engineer and Systems Engineer could have dramatically more in common than two Firmware Engineers. (Should the two firmware engineers be working in vastly different fields, while the other two engineers work in a similar field.). This adaptability reflects that the true work of engineering is defined by problems identified, and without this contingency the skills of engineering are devoid of purpose.

Fortunately the purpose of these skills is gifted by everyday problems — yielding those, ‘oh of course!’ moments after seeing a better means of doing something that you had never before thought to improve until seeing the answer. Smartphones, automated passport control and self-check out in stores are only a few of a large number of recent developments that have been culpable for these too-late-epiphanies. Informing these problem solving principles with problems from the outside world allow engineers to instead be the parties responsible for making these moments, rather than being subject to them. Applying these principles to the outside world can help us to reduce traffic using new methods of street separators, improve the safety of bikers by integrating modern technology with safety apparel, or by integrating the use of drones for delivery services.