Collection Types to Support
Document Actions
Submitted by
kef.
on 2007-06-21 13:40.
We are now supporting course and report as collection types. Kyle is building an interface to enter them when creating collections and so we need to decide what collection types to support. The blog entry discusses bibtex types and others that have occurred in our practice.
Bibtex supports (from http://bibtexml.sourceforge.net/btxdoc.pdf) article, book, booklet, conference, manual, mastersthesis, phdthesis, misc, proceedings, techreport, unpublished.
Do we need article -- or does that map to module well enough?
Connexions has encountered the need for course, report, textbook, journal.
In MARC (which I looked at only briefly, because I couldn't find a listing of types) I noticed "treaty" and "musical score".
How about the following for Connexions first version of CollectionTypes (with a bibtex mapping beside it):
- collection -- misc
- course -- misc
- report -- article or book
- textbook -- book
- book -- book
- journal -- i guess article -- couldn't find how to it
- magazine -- perhaps this is different in prestige claim from journal?
- proceedings -- proceedings
- manual -- manual
- NEWLY ADDED: guide -- manual -- Teacher's Guide will probably be a standard type needed
less sure about
- techreport
- score
- treaty
- thesis
Re: Collection Types to Support
Posted by
cbearden
at
2007-06-28 16:51
> Do we need article -- or does that map to module well enough?
I don't think a module is sufficient for modeling journal articles. Many articles if modularized would comprise 2 or more modules. Therefore I think 'journal article' must be a collection type.
'Journal' would be a collection that comprises smaller collections of certain types, including obviously 'journal article', but also maybe 'notices' and 'reviews'. I think we ought to be able to model a journal run as a collection type, but it's much lower on my priority list than (as well as being logically consequent to) 'journal article'. However, academic presses might conceivably want to publish their journals through Connexions.
In addition to 'journal article' there might also be 'encyclopedia article' one day. Both are called articles, but they are different enough to warrant different types, I think.
'bibliography' ought to be a separate type. It's probably less in vogue these days, but when I was a beardless youth in grad school, good scholarly bibliographies in literary disciplines were treasured.
Here are some items extracted from the MARC list of "nature of contents". The items I think *might* be useful are denoted with an asterisk. This is not a vote to implement them all now or soon.
Abstracts/summaries
Bibliographies *
Catalogs
Dictionaries *
Encyclopedias *
Handbooks *
Legal articles *
Biography *
Indexes
Discographies *
Legislation
Theses *
Surveys of literature in a subject area *
Reviews *
Programmed texts
Filmographies *
Directories
Statistics *
Technical reports *
Standards/specifications *
Legal cases and case notes *
Law reports and digests *
Treaties
In some cases, these might be better construed as module labels.
We might also want to consider letting editors lable their collections as "essays". Not so high a priority at this time.
For academic press work, I think journal article, book, edited book of chapters, proceedings, report, and textbook are essential. manual/handbook/guide are important. These could to some degree be synonyms.
This is quick (but too lengthy) feedback.
I don't think a module is sufficient for modeling journal articles. Many articles if modularized would comprise 2 or more modules. Therefore I think 'journal article' must be a collection type.
'Journal' would be a collection that comprises smaller collections of certain types, including obviously 'journal article', but also maybe 'notices' and 'reviews'. I think we ought to be able to model a journal run as a collection type, but it's much lower on my priority list than (as well as being logically consequent to) 'journal article'. However, academic presses might conceivably want to publish their journals through Connexions.
In addition to 'journal article' there might also be 'encyclopedia article' one day. Both are called articles, but they are different enough to warrant different types, I think.
'bibliography' ought to be a separate type. It's probably less in vogue these days, but when I was a beardless youth in grad school, good scholarly bibliographies in literary disciplines were treasured.
Here are some items extracted from the MARC list of "nature of contents". The items I think *might* be useful are denoted with an asterisk. This is not a vote to implement them all now or soon.
Abstracts/summaries
Bibliographies *
Catalogs
Dictionaries *
Encyclopedias *
Handbooks *
Legal articles *
Biography *
Indexes
Discographies *
Legislation
Theses *
Surveys of literature in a subject area *
Reviews *
Programmed texts
Filmographies *
Directories
Statistics *
Technical reports *
Standards/specifications *
Legal cases and case notes *
Law reports and digests *
Treaties
In some cases, these might be better construed as module labels.
We might also want to consider letting editors lable their collections as "essays". Not so high a priority at this time.
For academic press work, I think journal article, book, edited book of chapters, proceedings, report, and textbook are essential. manual/handbook/guide are important. These could to some degree be synonyms.
This is quick (but too lengthy) feedback.
Re: Collection Types to Support
Posted by
jenn
at
2007-07-18 12:19
Now that CollectionTypeChooser is in testing, I've continued the discussion of what collection types to use in trac ticket #3492 (https://trac.rhaptos.org/trac/rhaptos/ticket/3492).
Regarding 'techreport'--maybe the collection type as stored internally could be a brief token like this, but it could map to a better natural language phrase like 'Technical Report'.
Score: maybe not yet, but if authors publish scholarly musicology works in which there are whole modules of MusicXML by way illustration, it might be useful as a collection-within-a-collection type.