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
> to have the publishing pattern and document type be separate so they
> be combined in any way. For example, you can have maps that are
> 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
> 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