> It can say "give me the representative title" or "give me all of the
> displayable identifier fields", but not "give me the list of displayable
> ISBN's". That is, unless the caller assumes the field has a certain
> name, like "isbn", which is not a controlled vocabulary at this point.
> Are we ready to make the leap to defining a well-known base set of field
> names for display fields?
I think we should -- it would be preferable to using opaque IDs to
refer to them.
Looking at it from the POV of replacing MVRs, we've got several fields
that don't fit into the author/title/subject/identifier/series field
classes, including publisher, pubdate, edition, and toc. While I'm
not strongly attached to the notion of using 'display' as a new field
class, if we added it, we could refer to fields like this:
> In any event, a display-focused reingest function will make all future
> steps easier, so I'll look at that. We can change the function guts as
> needed.
> It can say "give me the representative title" or "give me all of the
> displayable identifier fields", but not "give me the list of displayable
> ISBN's". That is, unless the caller assumes the field has a certain
> name, like "isbn", which is not a controlled vocabulary at this point.
> Are we ready to make the leap to defining a well-known base set of field
> names for display fields?
I think we should -- it would be preferable to using opaque IDs to
refer to them.
Looking at it from the POV of replacing MVRs, we've got several fields title/subject/ identifier/ series field
that don't fit into the author/
classes, including publisher, pubdate, edition, and toc. While I'm
not strongly attached to the notion of using 'display' as a new field
class, if we added it, we could refer to fields like this:
display| representative_ contributor
display|title
display|pubdate
and so forth.
> In any event, a display-focused reingest function will make all future
> steps easier, so I'll look at that. We can change the function guts as
> needed.
Great, thanks!