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