Hi Karen, On May 23, 2005, at 10:33 AM, Karen Coyle wrote: > Just a note that you may find yourself painted into a corner when you > associate document types (i.e. "review", "newspaper") with genres that > relate to publishing patterns (i.e. "serial"). It may actually be > better > to have the publishing pattern and document type be separate so they > can > be combined in any way. For example, you can have maps that are > serials, > in that they are issued on a regular basis and may even have an ISSN. > And the one that always gets people in trouble is the "conference > publication" -- which can be a serial, a monograph (a one-off > conference), or an article in a journal (some journals sprinkle the > conference papers over a couple of issues). I guess the upshot is that > there is no set of categories that will not run into exceptions. Yes, I was realizing that. One possibility is for me to have generic categories too. So I might add a generic part class, and then flexibility. I've started to do that in fact, but as you can imagine, it's a bit difficult to figure out how to categorize some of this stuff. > The other question is: what is the purpose of the publication pattern > information in these categories? Is it just to help understand the > document types? Or is it strict? Both. If you choose, say, a genre of "article" the schema will mandate that you include a relatedItem host, that that host has a part element, and that it has an originInfo/issuance value of continuing. I also do stuff like: - if you enter a YYYY, YYYY-MM, or YYYY-MM-DD date, you must enter an encoding attribute and the w3dt value. - if you use an xlink:href, you must include the xlink:type ;-), and you may only use the part child - name roleTerms are constrained to subset of the marc list Bruce