¶ 1 Leave a comment on paragraph 1 0 The zinecat project is moving slowly forward, chugging along so to speak. There are several prominent issues I have encountered that I’d like to review here at the outset.
¶ 2 Leave a comment on paragraph 2 0 First, what drew me to the project was the assumed ease of development through the use of Collective Access (CA). While it is undoubtedly easier than building from scratch, it’s considerably more complicated than I anticipated. The primary road block the way in which CA handles metadata mapping. Simply conceptualizing the mapping process required hand-holding from more experienced users. It appears that mapping of dual xml files to one another is the primary way configuration is achieved, which, to me, seems strange at best. Admittedly, I have never used services similar to the one we are trying to build and don’t know if something more streamlined exists. For the most part, CA is an excellent sandlot for the zine union catalog (ZUC); I simply need more time to acclimate to its inner workings before I can really swim through its interface and mapping configs naturally.
¶ 3 Leave a comment on paragraph 3 0 Eric and Milo have really been essential in explaining many important details to me and the rest of the team. Trudging through the CA forums and wiki would have made a project even of relative small scale (as I would argue zinecat certainly is) painstakingly long. The most apparent example of their contribution was familiarizing the team with metadata mapping.
¶ 4 Leave a comment on paragraph 4 0 A Summary of Mapping in CA:
¶ 5 Leave a comment on paragraph 5 0 The initial install of CA required a schema profile that tells CA what exactly it will be working with. There are objects, entities, collections, places, et al., as well as relationships between these elements. For example, there exists a relationship in the ZineCore profile that defines “objects” as a limited array of possible types (physical zine, digital zine, audio zine, flyer, ephemera) and “entities” as creators of those objects with which they are associated. The schema profile used for the installation lays the foundation for mapping, and additional rules can be added in the post-installation process according to the needs and wants of the developer. These additions are implemented with an xmls file that provides a layout for how to interpret data sets being uploaded to the database. All uploads of data sets must then follow the layout that this xmls file used. Essentially, the mapping file dictates “column one is the object identifier; column two is the “object_type”; column three is the “entity”, etc.. Subsequent data uploads must then organize their metadata according to these respective rules wherein column one is a number identifying this particular item; column two is what type of object it is; column three is the author/creator.
¶ 6 Leave a comment on paragraph 6 0 The end-of-semester objective is for us to have created multiple mapping rule sets for various profiles that libraries are already using thus allowing them to easily upload their metadata to the ZUC database.
¶ 7 Leave a comment on paragraph 7 0 Second, I did not expect to be the sole developer of a project. I welcome the challenge and opportunity to learn. As the last class made clear, one of the essential skills I now have to learn is to manage digital projects in a way that ensures continuity and security of data. I am currently in the process of learning how to create a local clone of the ZUC through Git so that I am able to make changes to the site’s code without fear of irreparable damage. Using Git for this purpose will also make the development process open and visible to be used or adapted for other projects.
¶ 8 Leave a comment on paragraph 8 0 I believe this is currently my most important task because its completion cements all the work that has been invested towards building the ZUC. Using Git as a significant part of my data management plan will greatly increase the longevity of this project and will, in turn, ensure that it will continue to be developed and expanded beyond the scope of this semester.
¶ 9 Leave a comment on paragraph 9 0 The end-of-March objective is to create a clone of the ZUC as a repository on Git where I can make changes in a safe environment, to create an SSH connection through which I can push successful changes to the live site, and to develop a more comprehensive plan of what role Git will play in the ZUC data management plan.
¶ 10 Leave a comment on paragraph 10 0 This introduction to Git and this tutorial on managing a live site through Git are my current resources. I will reach out to Jojo and others for further assistance. My objectives prior to re-evaluating the need for Git implementation were to develop location hierarchies within the ZUC and to begin creating a mapping rule-set for the Denver library metadata standard. I believe that these goals may have to wait until the Git-specific objective is completed unless another team member chooses to prioritize them into their schedule.
