# Did My COR Just Teach Me Knowledge Management? So, here we are again—back in class, face-to-face, after those asynchronous sessions where we spent minutes watching KM videos and making sense of the whole data-to-information-to-knowledge chain. Honestly, I had been a bit anxious for this second in-person meeting. Not that I was terrified, but let’s just say I was cautiously optimistic. After all, during our first face-to-face class, the nerves were real, and there was a palpable tension in the air. But this time, it felt a bit different. Knowing our professor's unpredictable sense of humor helped cut through some of the anxiety. Still, you never know what kind of “surprise” activity might be in store for us. The thing is, our professor had already told us in advance to bring our Certificates of Registration (CORs) on September 2nd. This was originally planned for a "tearing of cedulas" reenactment—an ode to the Filipino revolutionaries during the Spanish era. But that activity got delayed because of an event at USeP, pushing it to September 9th. Of course, in the meantime, we had those asynchronous KM classes where I blogged about the previous videos and their focus on knowledge management. I came into class with all these thoughts swirling in my head about how data gets processed into information and then how knowledge is shared—thanks to those videos. So, I walked into this second face-to-face session with a mix of old and new knowledge, ready to see how it would all connect. But first, let me set the scene. When we entered the classroom, the tables and chairs were in this disorganized U-shape, a bit chaotic, and I noticed right away that no cedulas—or in our case, CORs—had been torn. "Okay," I thought, "What’s the deal here?" Was the tearing of the CORs just a symbolic setup for something else? Our professor, true to form, started with a prayer led by a classmate. But since his voice was barely audible, our prof made him repeat it louder, with the classic comment: “You’re the only one who can hear yourself.” Then came the history quiz. Sir asked if we knew why the Katipuneros tore their cedulas. I mean, we’ve all heard about it: it was a bold act of rebellion against Spanish rule. But the way he asked it, it felt like a metaphor hanging in the air, waiting to tie itself into our activity. I was curious to see where it was going. Now, onto the main event—the CORs. Our task was pretty straightforward: get into groups of at most five, analyze the COR data, and look for patterns, outliers, or trends. This made me flash back to the Kapture CRM video from the last blog. Just like how service agents were given structured knowledge to help them assist customers better, here we were, looking at raw data on our CORs, trying to process it into meaningful information. It was all about using data to see something bigger, just like in knowledge management. Our group quickly got to work. We laid out the columns: Registration No., Name, Date of Registration, No. of Units, Total Billings, Student ID, Paying Status, and Scholarship. Right away, we spotted some obvious trends. The registration number was directly tied to the date of registration. Makes sense, right? Register earlier, get a lower number. Simple. Then there was the direct relationship between the number of units and the total billings. Again, nothing groundbreaking. But one of our group members pointed out an outlier—one student had way fewer units yet had a weirdly high billing total when considering the standard ratio between units and billing total. Now, with such a small dataset (just the four of us), it was tough to draw any serious conclusions. But we knew that with a larger group, similar trends and outliers would likely emerge. When the time came for groups to present, I was ready. I even raised my hand, eager to explain our findings. Here’s the kicker, though—I didn’t actually hear the question that our professor had asked. My hearing has never been the best, and combined with the low volume of the lapel mic, it was like I was hearing through a tunnel. So there I was, raising my hand confidently, only to realize that I had no idea what the actual question was. Cue the embarrassment. I scrambled to answer something about why the billing statement was shown on CORs for non-paying students. In my rush, I mumbled something about government records, but honestly, I was so lost. Our prof, ever the sharp observer, noticed my confusion and had me sit down, which was—yeah—pretty awkward. Luckily, a classmate eventually got it right. The billing statement is shown to remind us that, while we may not be paying, someone is—specifically, the government. It’s a reminder of the public funds being used for our education. I had an “aha” moment right there. It all clicked. The data on the COR, which at first seemed like just random numbers, was actually processed into information that served a purpose beyond just us—it’s a financial record for the state. And just like that, my thoughts drifted back to the vidoes I watched during our asynchronous sessions. The idea of taking raw data and turning it into useful information for decision-making—it was all coming together now. What we were doing with our CORs was essentially knowledge management at a student level. Then came the follow-up activity: how could we use the information from our CORs to improve the enrollment system? My group immediately honed in on the issue of late registration fees. The paying students in our group pointed out that the delay in getting their billing statements often meant they had to register late, which resulted in extra fees. While this wasn’t exactly groundbreaking, we thought it was a fair observation. Yet, when I raised my hand to explain it, our professor didn’t seem impressed. He wanted a more direct, concise answer. I felt the sting of embarrassment again, especially when I could barely hear his feedback, and it felt like déjà vu—once again, I was confused and sat down without fully explaining myself. Despite my struggles, I learned a lot from that moment. Our professor explained that what we were seeing on the CORs wasn’t just raw data but processed information, derived from the Pre-Registration Forms (PRFs) we submitted. Those PRFs were unprocessed data—raw numbers and letters. But once processed, they became CORs, and from those CORs, the class master list was created. It was one big flow of data to information to knowledge, and suddenly, it all made sense. The data wasn’t just for us; it was part of a bigger system, feeding into something much larger—like the university’s statistical records, which would guide decision-making at an institutional level. Now, as if all of that wasn’t enough, our professor decided to go deeper into the world of machines. He reminded us about how computers can only read in bits—1s and 0s. He brought up the binary addition again, that quirky 1+1=10 thing that left a huge impression to me during our first meeting. But then he asked a seemingly simple question: “What does a compiler do?” I was ready this time and raised my hand confidently. “A compiler translates human-readable code into machine-readable code,” I said. But our prof wasn’t satisfied. He pointed out that the term “translate” might not be the best fit and suggested "convert" instead. I was caught off guard, feeling the pressure, and just agreed with "convert." Later that day, though, I Googled it and found that in nearly every source, "translate" was the term most often used in the definition of a compiler. It was a reminder that while "convert" might technically work, "translate" more accurately describes what a compiler does—it bridges the gap between two "languages," allowing code to move from human understanding to machine comprehension. This realization calmed me down, knowing that my initial answer wasn’t just instinctive but actually correct. It felt like a small victory, a quiet reassurance amidst all the classroom chaos. Then, as if that wasn’t enough to keep us on our toes, he asked another question: “What is an editor?” And again, me being a bit cautious (and maybe overthinking things), I thought he wanted a technical answer. So I said something about editors being where you input characters, which are bytes, that get converted to bits for the machine to read. Well, it turns out he was just asking for the simplest explanation—what an editor is in its most basic form. Once again, I felt that familiar flush of embarrassment. But this time, I learned to laugh at myself a bit more. By the end of the class, I felt like I had connected so many dots—from the KM concepts in the videos to the real-world data we were dealing with in our CORs. I realized that what seemed like just a routine activity was actually a microcosm of the bigger knowledge management systems we had been studying. Whether it’s in a university setting or a customer service platform, the principles are the same: collect data, process it into meaningful information, and use that information to make smarter decisions. I left the classroom reflecting on one key takeaway: knowledge, at its core, is about seeing the bigger picture from the pieces in front of you. As Albert Einstein once said, > "Information is not knowledge. The only source of knowledge is experience." And boy, was this class an experience. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://usep.gitbook.io/ice-311-blogs/september-2024/did-my-cor-just-teach-me-knowledge-management.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.