The last few weeks, I was mostly working with my mentors on enumerating new functions to add to the Metadata Environment and designing how they would fit in. I was also doing a lot of prototyping. This week, I started to really get into working on implementation.<\/p>\n
One portion of the Environment page contained places for a user to input information about the data set to be converted, so that this provenance could be recorded as metadata with the final RDF file. Before, this section containing three fields appeared when the page loaded. My mentors and I decided that asking for information like the name of the data set before the user had even loaded the file in question into the environment did not make sense, and might lead to confusion. We wanted to be sure that the fields for this info were visible, though, in order to make sure the user knows that they are important. An easy task for this week was repositioning the section of the Environment that requests this metadata, and hides it until after the user has loaded a file on which to perform enhancements.<\/p>\n
In the current implementation, when a user drags and drops the first property and class assignments for enhancement, the Environment creates two new rows between the column headers and the data itself. One of the improvements we wanted to make was to move the rows for property and class assignments into the column header label itself, both to save space, and to keep those three important pieces of information together. The three rows each need to have classes assigned to them when the table is first generated, too, in order to enable other features. For example, the row in the table for holding user-assigned properties should have a different style (such as bold red text) to indicate where the user has not yet made assignments. When the user is dragging a property, that row should highlight to show that it is a valid target for dropping properties.<\/p>\n
When I met with Patrice, Tim, and Evan this week, they also spent some time discussing handling of more complex enhancements, and how a user should be able to perform those tasks in the graphical user interface, as well. I think these conversations have been particularly interesting, because it has helped me get a clearer understanding of just how people recording data into tables will make decisions in how they record it to make it fit into the table structure. These decisions are things that can be easy to take for granted because they seem simple to human users – like putting the units for a measurement into a column header, or indicating a relationship between columns by coloring the column headers in Excel – but in order to convert this data into a linked format like RDF, the user must make these decisions explicit so that the computer can understand them, as well.<\/p>\n","protected":false},"excerpt":{"rendered":"
The last few weeks, I was mostly working with my mentors on enumerating new functions to add to the Metadata Environment and designing how they would fit in. I was also doing a lot of prototyping. This week, I started to really get into working on implementation. One portion of Continue reading Week 4 – Adding new functions!<\/span>