Reading #9

Foulonneau, M., &  Riley, J. (2008). The future of metadata.  In Metadata for Digital Resources: Implementation, Systems Design and Interoperability ( pp. 187-197).  Oxford: Chandos Publishing.

Metadata began as a simple set of functions, primarily for cataloging.  Increasingly, the flexibility and extensibility of metadata are gaining value.  A new challenge facing the cultural heritage sector is the development of new ways of gathering large amounts of data (conceptually), relating it to the relevant resources, and using and reusing the metadata across a wide spectrum of applications.  The authors address four trends that are influencing and will continue to influence metadata work in the years to come.  Automated metadata generation is predicted to continue its place in digital workflows.  Some types of metadata are better suited to automated generation and others, like descriptive metadata, can pose a problem.  DC Dot is a tool that can be used to automatically generate metadata from web pages.  The tool can suggest keywords after an analysis of the text.  Tools like these are still in development and manual generation is usually also needed.  The second trend is the influence of Web 2.0.  The authors predict that user participation, such as recommendations/reviews, tagging and content sharing will have great potential for enriching digital library applications.  The third trend concerns strategies for metadata management.  The authors suggest broad and accommodating, yet clearly defined usage conditions for metadata records in order to provide the best possible flexibility for future use.  Lastly, the authors suggest that as metadata changes, so must the institution’s mission statement.  Particularly, the mission statement should address the issue of cooperation between institutions.  The institution’s ability to position itself directly inside the circle in which its users and colleagues exist is directly related to its ability to fulfill its primary mission.

Week 29: Wrapping Up

So, not much can be said of this week.  Unfortunately, the work on Vict Bib that other people were doing is not finished yet, so I cannot complete my part.   I am quite disappointed and really wish that I could have left here on a high note.  Instead of writing about what I did this week, I thought I'd wrap up this blog addressing a question that I actually have been asked multiple times by multiple people outside of the library/information science world. The question is, "what are the differences between HTML and XML?"  I have tried in many ways to answer the question, but for once and for all, I want to have my answer here. 

So, what are the main differences between HTML and XML?  (Not in any particular order)
1. HTML is static, but XML can carry data between platforms, so it is dynamic.
2. HTML has pre-defined tags, while XML is more flexible and allows the inclusion of custom tags created by the author of the document.
3. HTML is more relaxed about closing tags than XML.
4. HTML was created for design and presentation, whereas XML was originally meant to transport data between an application and a database.
5. The most important distinction is that HTML is concerned with how the data looks, but XML exists to describe the data and is concerned with presentation only if it further reveals the meaning within the data. 

So, I guess I need to write down a quick breakdown of what I have done during my time here at the DLP.

1. I have rewritten the Schematron for validating TEI-encoded Victorian Women Writers Project texts.  Through this process I have had experience with XML, XPath and quality control of electronic texts while increasing my comfort level with TEI. 

2. In collaboration with metadata experts across IU Libraries, I helped to define a core metadata set for use in the ICO and Photocat.  I developed my analysis and survey-writing skills while juggling thinking both broadly and on a small scale.  I became acquainted with MODS while mapping the Photocat fields to MODS and then later tweaking existing XSLT and drafting a new XSLT for the new core set. 

3. I was introduced to METS during the METS Navigator project.  I came to appreciate the transition and great amount of work necessary to migrate sets of data from one iteration to the next.  I did further mapping and analysis work and tried my hand at writing specifications to be turned over to programmers to create a new and improved METS Navigator 3.0 with pop-up found through finding aids. 

4. The last project, as short as my time with it was, allowed me to work with CSV files- a format I had not worked with before- and introduced me to online data extraction tools (cb2bib, text2bib).  I also came to have a greater understanding and respect for the steps necessary and the care it takes to migrate large amounts of data. 

Although I knew that working in any environment with other people demands a great deal of patience, I have to admit my patience was tried multiple times here, especially the last part of my second semester.  While I was frustrated a lot in the beginning of my internship, that was more with myself, trying to figure out Schematron.  This time, I became frustrated because I felt I had to wait a lot for people to finish their part of the project until I could do my part.  I don't blame anyone, and I understand it is just part of a working environment.  That being said, I really valued my time here and I can honestly say I've learned more than I could have by just taking classes.  I dont' know what the future holds for me, but I know I am better prepared than I was before my digital library life. 

Week 28: Working with CSV files

Michelle had asked me to try and figure out how the best way to handle Vict Bib  records that have multiple authors.  The data will need to be extracted as discretely as possible.  The problem right now on the Vict Bib website is that multiple authors are displayed as one entity.  Also, there are some glitches where editors, authors and translators are interchanged, mostly when a user performs a search.  It seems like a bit of Drupal might solve the problem.  The Feeds Tamper module provides preprocessing functionality before the data is mapped to the entity fields.  The Explode plugin will "explode" the values into an array.

I then met with Michelle and we discovered together that the CSV file will need to be tweaked to transform the commas into pipes.  Commas can be used for other instances, for example, in titles.  So, the best thing is to used the "|" instead.  However, this requires that we control CSV export.  Michelle recommends that we pass on what I've worked on so far to the programmers to see what kind of export they can provide for me.  From there, I will start the ingestion of either the CSV file into cb2bib or BibTeX into Zotero.  I only have five hours of my internship remaining, so it will have to be one or the other. 

Reading #8

Weir, R. O. (2012).  Making Electronic Resources Accessible. In Managing Electronic Resources (pp. 69-86). Chicago: ALA.

 

All libraries need to develop the best possible service and be responsible for the development and maintenance of online access tools, regardless of the variations between and situations within each library.  Having selected appropriate tools, or at least the best tools available, it is important for librarians to remember the purpose of these tools and what libraries need to do.  Libraries and librarians are in competition with other information services and there needs to be a focus on how users actually find information.  The chapter outlines some general principles that should guide librarians in the development of a successful ASER (access system for electronic resources), regardless of the online access tools that are chosen.  1) Provide quality metadata,  2) ensure convenience for the user, 3) simplicity is best, 4) eliminate all unnecessary steps to access content, 5) make branding ubiquitous, 6) solicit feedback and 7) make assessments. 

Week 27: Working with bibliographic data

After completing the list of Vict Bib fields I moved onto make the decision to use cb2bib for the data extraction.  Once I decided that, I began to read manuals on cb2bib configuration. It appears that I may have to do some command line work, so I will need to look into that more. While researching cb2bib I also found some information about BibTeX (the format cb2bib will turn the CSV file into).  I learned that BibTeX is a reference management software for formatting lists of references.  The software makes it easy to cite sources in a consistent manner, by separating bibliographic information from the presentation.  Zotero supports this software and can be used to output BibTeX data.  After completing this and bringing all of this together in my mind, I began the process of mapping the Vict Bib fields to BibTex fields.  Mapping to me is like a puzzle and I really enjoy that part.  It's like translation and as a language person, I understand it pretty easily.  While there is not always an equivalence between fields, it's fun and challenging trying to find the closest elements. 

Week 26: cb2bib or text2bib?

I didn't do many things this week, but I really got into the Vict Bib project.  Earlier in the week I began a list of Vict Bib fields based on a spreadsheet and an examination of possible fields on the website.  This was a loooooong process because there isn't a way to have the website automatically display all fields.  I had to scroll through many records-pages and pages actually-in order to make sure that I had identified all of the fields. 

Later in the week I started reading documentation on cb2bib and text2bib.  The cb2Bib is a free, open source, and multiplatform application for rapidly extracting unformatted, or unstandardized bibliographic references from email alerts, journal Web pages, and PDF files. Text2Bib is a PHP script for converting references to BibTeX format.  However, it seems like it cannot detect some of the document types that Vict Bib uses.  Lastly, I read quite a few forum posts on the subject of data extraction.  So, again, this week was not much "doing", but a lot of preparation for what's to come. 

Reading #7

 

Weir, R. O. (2012).  Gathering, Evaluating and Communicating Statistical Usage Information for Electronic Resources. In Managing Electronic Resources (pp. 87-119). Chicago: ALA.

When evaluating e-resources, it is vital to take a close look at the usefulness patrons derive from them compared to the investment, such as purchasing and licensing.  The importance of usage data and statistics in making and justifying e-resource renewal decisions is substantial.  The challenges faced in gathering data, creating and processing statistics, and reaching responsible conclusions are quickly increasing.  Prior to tackling these challenges, an evaluator must be certain of what he or she wants to achieve and how he or she is willing to tackle it, deciding upon a scale of usage analysis that is meaningful and sustainable in each library’s individual context.  The library and user communities must be aware of the subtle variations that exist in the definitions of usage between vendors.  The attempts to achieve standards, and the nuances of specific data items equip the librarian to use usage data wisely. 

Week 25: More possibilities

This week I think I have finished the Schematron work.  Really, I really do!  I have the encoder checks, editor checks, biographical introductions and critical introductions.  I have put them up on the Wiki and after Michelle looks at them I can then put them on Xubmit so that encoders can later download them to check their work. 

I also had a nearly two hour meeting with Michelle to talk about METS Navigator work and a new project assisting with migrating the data from Victorian Studies Bibliography.  Right now all of the data is on a website, but due to lack of support and time to devote to the maintenance of the website, the website will be shutting down.  In order to preserve the data, the plan is to move it to Zotero.  Michelle would like me to do two things:  map the Vict Bib fields to BibTeX fields (BibTeX is a format that Zotero supports).  Secondly, she would like me to find a tool that can extract the data from the CSV file into BibTeX. 

I also attended the Digital Library Brown Bag on the William V.S. Tubman Photograph Collection. The presentation reviewed the history of the project, from removing old, decaying photographs from a damp library in Liberia to providing public access to these photos via Image Collections Online.  The speakers stressed the large role of IU's Digital Library Program through their contribution and provision of digital library infrastructure and related tools.  This presentation was further confirmation for me of what excites me about the possibilities of digital libraries and digital collections. 

Reading #6

Caplan, P. (2003). MOA2 and METS. In Metadata Fundamentals for All Librarians (pp. 161-165). Chicago: American Library Association.

This book’s section on METS begins with its history: In 1997 the Digital Library Federation began a project called Making of America II.  Then, in 2001, a workshop was convened to discuss modification of MOA2.  A result of the workshop was a successor format, known as METS.  The section continues on to describe the differences between MOA2 and METS.  METS, unlike MOA2 has a header section containing information about the METS file itself as well as a behavioral section detailing information about behaviors associated with the object.  Another major difference is the external metadata record or embedded metadata from a non-METS namespace within a wrapper element.  The author recommends the external metadata record as a way to avoid maintenance issues that could arise due to changes in standards or project focus.  The many parts of a METS file are then listed, along with a brief explanation of each of the subparts.  For example: The ‘fileSec’ groups information about files related to the digital object within a wrapping.  The ‘FLocat’ subelement can be used to link to the actual file.  The author demonstrates well the impressive flexibility and extensibility (through the extension schema) of METS through outlining its history and providing sample file excerpts that show METS’ many potential uses.

Week 24: Library of Congress fellowship?

So, last week I found out about this Library of Congress fellowship.  It's a nine month position where you get to work at one of several D.C. digital libraries/humanities institutions.  I think I may apply because it seems like it may be interesting and a good stepping stone.  In order to prepare, I did a few hours this week researching the Folger Shakespeare Library and MITH.  I also did some work on improving my resume. 

Again, I attended the Digital Library Brown Bag.  Stacey Konkiel, the E-Science librarian and Heather Coates (remotely from IUPUI) did the talk.  It was on the university-wide suite of data services that librarians have developed to address the need for academic libraries to evolve to include research data curation and management services.  Most of these services seem to be used primarily by science faculty and students, but a small number of services exist to provide support and platforms for social science and humanities scholars.  I admired how the speakers emphasized the need for campus-specific resources, given that the Bloomington and IUPUI campuses tend to possess slightly different research and output emphases. 

To round out the week, I continued the JavaScript tutorial. 

Reading #5

Liu, J. (2007). Metadata implementation.  In Metadata and its Applications in the Digital Library: Approaches and Practices (pp. 124-125). Westport: Libraries Unlimited.

Within the Metadata Implementation chapter, there is a small section on crosswalking that begins with a quote from the Dublin Core Metadata Glossary that states that “crosswalks help promote interoperability”.  The author then moves on to define a crosswalk as a “high level mapping table for conversion”.  Such a method leads to inevitable sacrifice of data, because it is almost impossible to match all of the elements in the original schema with those of the other schema.  No two metadata standards are completely equivalent.  While this can be useful to pick and choose a schema which best suits a project, it can also be detrimental when trying to transfer data from one metadata standard to another.  The author mentions several projects that have used crosswalks extensively, such as Michigan State University’s Innovative Interfaces XML Harvester, which is a tool to help convert the collection-level information in EAD into MARC.   METS is described as an example of a standard that avoids transformation problems due to its acceptance of descriptive metadata in any format regardless of local rules or standards.  In a time where standards are constantly shifting and advancing, METS is an invaluable tool. 

Week 23: XSLT, METS, JavaScript, oh my!!

So, this week I seemed to have dabbled with a bunch of things.  I continued reading from 'XSLT Quickly' by Bob DuCharme and got as far as adding and deleting elements.  But as it turns out, I actually won't be writing the XSLT for transformation.  It seems the programmers want to use Java and want to do this transformation themselves.  So, I will just write a draft XSLT anyway for the practice, although it won't be used. 

I then got my METS experience for the week by updating the METS comparison documentation ever so slightly so that the wording is a little more clear. 

Then, since I have to wait to hear from Michelle about my next step, I decided to finally sit down and do some JavaScript tutorial work.  I want to eventually use JavaScript for my Hildegard project, so since I had the time I decided it was the perfect moment.  I spent about 3 hours working on that.  I used the W3 schools site for that: www.w3schools.com/js/js_intro.asp .  I really like their tutorials.  They're not super comprehensive, but they are good basic starting off points. 

I also attended the Digital Library Brown Bag.  This week, DLP's own Julie Hardesty gave the talk.  She is the Metadata Analyst/Librarian here, and she and I worked together on the ICO/Photocat project. Her presentation was on the IU Libraries' using CSS media queries to offer mobile-ready access to online digital collections.  I liked how she had us take out our smartphones (if we had them) and compare the different displays and how the page was rendered.  Apparently, there are two ways a mobile phone can display a web page.   One is to create a completely separate site, a mobile site.  You can tell if a site is a mobile site by whether or not an 'm.' is located in front of the rest of the URL.  Or, the CSS can be written to automatically render the display so that it can fit the screen, whether it is on an iPhone, Android or iPad.  This was an interesting talk and at the end Julie read a funny poem she wrote called 'Making Mobile Meaningful' that was written using only words starting with 'm'.  Clever!

Reading #4

Foulonneau, M., &  Riley, J. (2008). Technical interoperability.  In Metadata for Digital Resources: Implementation, Systems Design and Interoperability ( pp. 154-164).  Oxford: Chandos Publishing.

This section of the book describes how metadata can be used to represent complex or multi-part resources and outlines best practices for interoperability.  The METS (Metadata Encoding and Transmission Standard) Schema is the most heavily used schema for complex resources in the cultural heritage field.  METS files are unique in their ability to include the set of files that make up the digital resource, structural metadata, descriptive metadata, administrative metadata and behavioral metadata.  Furthermore, the METS schema does not mandate which metadata formats should be used to describe the resource, but more so acts as a container that holds all of the metadata formats involved in describing the digital files together.  For example, the METS Navigator application, developed at Indiana University, uses the structural map and pointers defined in the METS file to access the multiple parts of the object.  Together with a page-turning interface and user-friendly navigation, METS Navigator provides simple, intuitive and high-level browsing, flipping and searching capabilities.  Concerning interoperability, the authors discuss several challenges in technical interoperability, such as information loss and ensuring accurate description of the desired entity, otherwise known as the one-to-one principal.  Metadata mapping, the practical stage of technical interoperability, is outlined with a section on mapping tools.  Methods using XSLT stylesheets, Java, Perl and Python are briefly discussed.   

Week 22: Mapping METS

I finished up the comparison documentation and then started looking at Best practices for METS at IU and reviewing the specs.  I then also looked at guidelines for mapping TEI to METS to see some sample METS XSLT.  I will probably write XSLT to transform from METS Navigator 1.0 to 3.0.  I then read a few chapters from 'XSLT Quickly' by Bob DuCharme and also studied from www.w3schools.com/xsl/default.asp.  I didn't actually do many things this week, but it actually took a lot of time, since a lot of it was reading and studying. 

Week 21: METS comparisons

I met with Michelle again this week to talk about how to start documenting the comparisons between the document for targeted METS Navigator 3 migration with various METS Navigator 1.0 files.  Using a spreadsheet I have started the comparison work.  What I did was break the document into the 5 METS sections that the DLP will use.  Then I created a column for the target and then individual columns for the METS Navigator 1.0 sample documents.  This way, one can see clearly the differences between 1.0 and 3.0 for the Root or File Section.  I also highlighted the parts that I thought were exceptional or contributed to a very important difference.  For example, I noticed that in the logical part of the Structural Map, the TYPE="logical" is what provides the side nav.  If there is no LABEL that indicates each page or section level div then this information will not appear in the side nav.  Or, better said, the side nav will be suppressed.  After creating the spreadsheet, I wrote a clearer and more verbose Word document explaining all of the differences that will then be used to do the transformation.

Reading #3

Marshall, C. C., & Bly, S. (2005). Turning the page on navigation. In Proceedings of the 5th ACM/IEEE-CS joint conference on digital libraries, (pp. 225-234).

This paper presents the results of two observational studies on reading and document navigation behaviors in serials. The first study documented readers interacting with paper serials, and the second study examined the same users interacting with digital serials. The authors discover that readers of magazines, journals, textbooks, anthologies do not read the entirety of these materials or read the documents from beginning to end - rather, they skim, skip, and scan the material. Navigation must support this type of use, particularly by providing some type of "lightweight navigation" and flipping capabilities. Lightweight navigation includes behaviors such as focusing in on specific sections of a page or glances back or ahead in a document. In paper form this might entail folding a newspaper so that only one or two columns of text are visible. In digital form, a reader could zoom in on a page to simulate the same effect. Flipping allows a fast visual scan of a serial. It is more problematic to provide this type of navigation in digital form, but thumbnail scrolling might be one solution. Jumping behaviors that occur during paper serial reading are much more difficult to render in digital forms. Metadata may offer comparable functionality by allowing readers to navigate to subsections of a document or to other articles in the periodical, but this type of navigation is far less fluid.

Week 20: Wrapping up Schematron?

So, this week I finished up the rest of the Schematron work, with the Encoder and Editor checks.  I still had a few questions about the work, and I included these as comments in the file.  For example, I was supposed to test that there was a head tag immediately following a div.  However, that rule would be too strict, since sometimes a pb (page break) intervenes.  In addition, not all the divs have heads, especially the ones that are within floating text.  So, my issue is how to write that so that Schematron catches only the divs that are supposed to contain a head that don't.  So for now I think I'm done with Schematron, but will probably have to go back to it in the future since I have lingering questions. 

I continued the readings on METS Navigator as well and then moved onto analyzing some METS documents in order to understand their architecture.  I learned that there are 7 sections of a METS document: Header, Descriptive Metadata, Administrative Metadata, File Section, Structural Map, Structural Links and a Behavioral Section.  The Header, File Section and Structural Map will be the most important sections for METS Navigator purposes.  The Structural Map is the only section that is required in a METS document and both it's physical and logical sections are the most important for the METS Navigator page turning service.  The logical section provides the hierarchy and side nav so that a user can jump to a specific section within the electronic text.  So,  I'm going to try and pay most attention to this section. 

Week 19: Go METS!

More work this week on Schematron editor and encoder versions.  Not much to report other than I keep finding new ways to test.  I think I've found the best way and then I realize that no, there's a better way that is more reliable or comprehensive.  I started the next step for Schematron which is checks for critical introductions and bios.  The critical and biographical introductions are authored by students and accompany the source literary texts.  There are specific encoding guidelines for each which means that I need to spend a little time learning these guidelines in order to decide what needs to be checked.  Like with the TEI Header and body checks I still need to check for all of the '$' template values to make sure they are gone.  I need to check for xml:id="encoderusername".  For the intro checks specifically I need to make sure that the first part of the xml:id and the <idno> match the related text with regards to the value of @ref.  In other words, the 'nnnn' part of the xml:id="VABnnn_intro" needs to match the numbers in @ref.  For the bio checks I need to make sure there is a notesStmt and to make sure there are two line breaks after each header.  Now that I've had more practice, this has come a bit more easily to me. 

My next project is going to be working on writing the specifications and drafting XSLT for the eventual migration of data from METS Navigator 1.0 to METS Navigator 3.0.  METS Navigator is used here at IU for the page turning service.  Now, most of the page service is stand-alone, but soon DLP wants to change that into a pop-up.  In order to have that happen, the data needs to be moved.  I have started doing some readings on METS Navigator in order to understand its history and capabilities.  I look forward to starting work with METS.  Plus, I like the name, being a New Yorker and all. 

Reading #2

Weir, R. O. (2012).  Acquiring Electronic Resources. In Managing Electronic Resources (pp. 37-51). Chicago: ALA.

Traditionally, the acquisition phase focused primarily on ordering, receiving and paying for proprietary published materials.  In the online environment, however, the responsibilities have expanded.  When ordering electronic materials, librarians encounter more exceptions to the rule and cannot assume that the resource type will dictate work flow.  Instead, other important traits should be considered- such as quantity, purchase type, costs, archival rights, vendor and license terms- that will influence initial and ongoing purchase procedures.  In addition, the librarian is responsible for gathering and distributing information that will determine the access and discovery setup process.  The action items may be performed by the librarian or passed to other colleagues, depending on roles and responsibilities.  Electronic resources are constantly changing and evolving.  As such, this chapter is only an overview of considerations identified at one snapshot of time.   By no means is it intended to be a definitive and exhaustive “encyclopedia” of acquisitions issues, but rather a sampling of possibilities in the online environment. 

Week 18: Librarian as Supporter, or Scholar in her own right?

This week I was feeling much better, but I decided to take Monday off to fully recover.  On Wednesday I attended the Digital Library Brown Bag talk.  This week it was presented by my supervisor Michelle Dalmau and she talked about her experience at a Digital Humanities and Libraries THATCamp.   Many of the participants felt that their discussions and experiences would help other digital librarians to better define and promote their unique roles as information professionals.  I was particularly struck by how many librarians, digital librarians specifically, seem to want to get away from the notion or idea that we are solely in a service position.  They seem to want to prove to faculty members and professors that they can participate in research in addition to supporting research.  This active role is what I desire to have and I loved that this was brought up.  However, I don’t think being in a service role is necessarily a bad thing.  This is what at first drew me to librarianship.  My views and emphasis have shifted a bit as I have become a more skilled and experienced librarian, but we can’t forget our duty to our patrons and information seekers at large. 

After attending the talk, I edited the Schematron I have been writing.  There were a few issues with it and so I spent some time editing it for the body, encoder and editor versions.  I also worked on MODS mapping for the core fields.  There was a bit of a template to work with, but most of it I had to do from scratch.   When there were some lulls in the day I continued reading on electronic resources. 

Week 17: Sick Ness

This week I had the flu.  I came in to the office on Monday and continued some work on the Schematron body checks.  I then moved on to doing some more reading on electronic resource acquisition.  I have been interested in that for some time, but I have never really had much experience with it.  I work with electronic records a bit, but I have always wondered about their acquisition and management.  After working for about 3 hours I knew something was wrong when I felt like I had been hit by a truck and couldn’t stop sneezing.  I decided that my bed was where I needed to be and I ended up staying there for the rest of the week.  

Reading #1

Weir, R. O. (2012). Coping with Economic Issues and a Paradigm Shift in Collections.  In Managing Electronic Resources (pp. 17-36). Chicago: ALA.

The economic recession and the resulting decreased or flat budgets have pushed librarians to come up with creative ways to persevere and continue providing patrons with excellent customer service and better chosen resources.  Many librarians have reevaluated collection development models, implementing pay-per-view and patron-driven acquisition ideas and relying on interlibrary loan to fill patron needs.  Some other ways to face an uncertain financial future include partnering with library consortia for reduced rates on electronic resources, canceling “big deals,” using open-source, freely available to libraries worldwide, homegrown ERMSs, and evaluating electronic resources using COUTNER usage statistics.  While it is impossible to predict what the future holds, it is likely that librarians will continue collaboration with one another and with publishers on finding solutions to continue serving their patrons’ needs. 

Week 16: Back at it!

This week I was back at the DLP after winter break.  I was looking forward to getting back to work especially since I felt like I was on a roll before with the Image Collections Online work.  Immediately I got into the process of beginning to define the Photocat core fields and put that information into the Wiki.  Before I had left for winter break, the Metadata Working Group had narrowed the core set down to 12 fields.   Now, the core set had expanded a bit, to 16 fields.  The working group added ACCESSION_NUMBER, CALL_NUMBER, DATE_TAKEN and STATUS.  These fields were added after we received feedback from collection managers and other users of Photocat. 

In addition to defining the core fields, I moved onto defining the remaining non-core fields.  These include over 75 fields that are either too specific to a collection to be included in the core, or are just not used very frequently by any collection.  The definitions for these fields were a little more complicated due to the fact, as mentioned before, that many of them are collection specific.  There were other fields that were a bit confusing.  The difference between PHOTOGRAPHER_STUDIO and PHOTOGRAPHIC_AGENCY is negligible and to write a clear definition that captures that slight distinction is difficult.  But it is necessary to do in order to provide catalogers with the best possible field to describe their collection. 

On top of working on ICO stuff, I also continued work on Schematron for the body of the document.  These are slightly different and while there are not as many checks, the XPath and queries may be a bit more difficult.  I can tell I am really using my XPath skills and understanding-of-XML-document chops.