Talk:ESciDoc Application Profile Publication

General

 * String data type definition
 * Question: Is the given definition appropriate?
 * Robert: "Ein string kann doch enthalten was er will, nur wenn er in xml kommt muss man halt escapen. In dem Fall Metadata description mit xml syntax vermischt"

Creator & Contributor

 * Creator: is the element really mandatory?
 * Author, which we want to use dc:creator for, is also defined as a MARCREL (see refinements below), but then as a refinement from dc:contributor.
 * Painter does not exist as MARCREL.


 * dc:creator is used against DC semantics. Two options:
 * introduce the understanding of "primary creator" to pubman (-> could be stored in dc:creator)
 * use the dc:contributor element + role (re-use from loc)

dc:creator versus dc:contributor & the usage of creator role
Please note that the following section is the documentation of a decision process vibrating between several options, but without result until today:


 * There is a proposal from LOC to use the MARCREL relators both, in dc:creator and dc:contributor: http://www.loc.gov/marc/dc/Agent-roles.html; However, the proposal is from 2002 and I have no information wether or not is was ever implemented that way --Andreas Gros 09:40, 17 September 2008 (UTC)
 * It was implemented that way here: http://richard.cyganiak.de/2003/xml/publishing/ (creator with the dole aut)
 * The ePub format use a role attribute for dc:creator as well, see http://blog.threepress.org/2009/11/27/practical-epub-metadata-authorship/ --Inga 15:24, 27 November 2009 (UTC)
 * And OCLC proposed it at some point: http://www.oclc.org/research/projects/mswitch/1_gem-marc.htm --Andreas Gros 09:47, 17 September 2008 (UTC)
 * The OLAC Role Vocabulary from 2006 also recommends refinement of dc:creator and dc:contributor: http://www.language-archives.org/REC/role.html. From the abstract: [...] (Please note that Dublin Core now discourages the use of the Creator element, recommending that all Role information be associated with Contributor elements.)[...]
 * I don't know where the OLAC-people got this information, but when I ask people here at the DC-2008 conference, they tell a different story (creator is still one of the most prominently mentioned elements) --Andreas Gros 08:04, 22 September 2008 (UTC)
 * Just heard another facette of this song: creator is a subproperty of contributor in the last version of the dcterms-document: http://dublincore.org/2008/01/14/dcterms.rdf#Creator --Andreas Gros 12:00, 22 September 2008 (UTC)


 * I looked up the example of MARC-Relators and found out that most of these relators redefine dc:contributor and not dc:creator. In fact, MARCREL:CRE (creator) is the only refinement of dc:creator (compare http://lcweb2.loc.gov/cocoon/loc.terms/relators/dc-relators.html). Even "MARCREL:Author" is a refinement of dc:contributor. Do we have to define our own eSciDoc:author that refines "creator" to use it as a creator-role? (see http://memory.loc.gov/cocoon/loc.terms/relators/dc-relators.html) -- Andreas Gros 14:43, 31 March 2008 (CEST)


 * What is our understanding of the property "creator"? Do we actually mean "contributor" with different roles? Do we use creator for "the main or leading author"? Recommendation from meeting with Natasa, Ulla, Malte, Andi, Inga: Replace dc:creator by dc:contributor.


 * Just to remark:
 * dc:contributor - An entity responsible for making contributions to the resource.
 * dc:creator - An entity primarily responsible for making the resource. Frank 08:51, 11 March 2008 (CET)


 * Currently, the pubman metadata schema not complies with the distinction between "primarily responsible" and "contributed" made by dc. We only have entities (persons/organizations) which participated in content generation and their specific role (e.g. author, editor, etc.). It was argued that all pubman creators with type "author" are dc:creators and pubman creators of any other type are dc:contributors. Two contra arguments:
 * for proceedings and edited books, a creator of type "editor" is probably the entity primarily responsible for making the resource
 * for journal articles with more than a handful of authors it's quite reasonable that not all of them has been primarily responsible for the publication (see edoc example). But the person entering the record in PubMan does not necessarily know which creators are dc:creators in the core sense (as we understood it now) and which are not. In addition, we have no use case which requires the distinction introduced by Dublin Core BTW: As you can see in the edoc example provided above, the authors are not listed alphabetically, but the order encodes their importance for this paper, see http://www.sciencedaily.com/releases/2007/11/071105103938.htm. Please note that we will consider mapping the first creator to dc:creator for transformations to dc simple. --Inga 20:19, 11 March 2008 (CET)


 * Traugott made the point, that we must not over-interpret the dc comment on primarily responsible. The standard use case is that each author of a paper is a dc:creator, no matter how important they were in creating the article. Each creator can be given a corresponding creatorrole. The cases in which contributors are used should follow best-practices, like:
 * *http://dublincore.org/documents/usageguide/elements.shtml
 * *http://www.lib.ncsu.edu/cataloging/metadata/NCSUcore1.html


 * Most importantly, using dc:contributor as a replacement for dc:creator would decouple eSciDoc from most external search-engines because the common property to be looked up when searching for an author is dc:creator and not dc:contributor.
 * It fine for me to use esciDoc specific creator element with roles (this is what we are currently practicing). Does anybody expect us to provide a more detailed mapping (e.g. an illustrator of an article is dc:contributor but no dc:creator)? --Inga 10:28, 13 March 2008 (CET)


 * Another proposal:
 * Let's use dc:creator as well as dc:contributor and map all creators which are specified to be the author (MARCREL:AUT) to dc:creator (without refinement) and all other creators to dc:contributor (with refinements after MARCREL and more if required). Please note, that this would require us from removing the "mandatory" for dc:creators, but maybe we could add mandatory to dc:contributor instead (because dc:creator is a sub-property of dc:contributor) --Inga 11:53, 17 September 2008 (UTC)


 * Why do we not just use dc:creator with different roles (as dc:creator is a sub-property of dc:contributor) and use the MARC-Relators for dc:creator? --Kristina 12:58, 2 October 2008 (UTC)


 * We do not need the distinction between dc:contributor and dc:creator in pubman. It might be confusing and I would prefer to keep the data model as simple as possible. So my proposal is to use just dc:contributor with the role "author" for creators. If necessary we can identifiy the dc:creator by role "author". I will address this issue at the next metadata meeting (probably at beginning of November) and we must come to a decision. --Kurt 10:45, 28 October 2008 (UTC)

Missing roles

 * For dc:contributor: Besides the MARC relators we use, eDoc additionally uses "Archivist", "Preservator", and "Referee" as contributor-roles. Shall we add them as eSciDoc-relators?

We currently try to avoid "Archivist" and "Preservator". In addition, it could be that eDoc's "Referee" is semantically identical to Marc's Reviewer (http://www.loc.gov/loc.terms/relators/REV) or Marc's Thesis Advisor (http://www.loc.gov/loc.terms/relators/THS). Notes:
 * The role "Referee" is used by 136 public entries on eDoc, the most of them are Thesis, PHD-Thesis and Dissertations. These publication often distinguish between author, advisors (= official Gutachter) and referees (= MPG responsibles), see edocID 357180. --Inga 12:06, 17 September 2008 (UTC)
 * According to the IFLA Universal Bibliographic Control and International MARC Core Programme (UBCIM), a reviewer is a "Person or corporate body responsible for the review of a book, motion picture, performance, etc". This has nothing to do with our "Referee". --Inga 13:06, 17 September 2008 (UTC)

Suggestion:
 * advisor to become "thesis advisor", (= "Person under whose supervision a degree candidate develops and presents a thesis, mémoire, or text of a dissertation.", see UBCIM) = http://www.loc.gov/loc.terms/relators/THS
 * referee to become "scientific advisor" (= "Person who brings scientific, pedagogical, or historical competence to the conception and realization of a work, particularly in the case of audio-visual items", see UBCIM) = http://www.loc.gov/loc.terms/relators/SAD


 * I think the suggestion above is intuitive, and we use that definition for Japanese translation of PubMan R4 UI. Please let me know if the policy or the label is changed. Masao 08:10, 19 January 2009 (UTC)

Source

 * dc:source is used against DC semantics and should be changed to "isPartOf". In addition, the element bibliographicCitation has been created to improve interoperability (should be available twice: maschine-readable as well as human-readable). See also: Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata (comment from the eSciDoc Application Profiles Discussion page; user unknown).

Event

 * C-DOC CRM standard event element?

Subject
Vocabulary:
 * Dewey Decimal Classification (DDC).
 * Library of Congress Classification (LCC)

Discussion:
 * Traugott strongly suggests to use DDC, because it is the only system adapted to online usage and which is maintained and enhanced continuously. It is also fine-grained enough to allow the classification of a large number of documents, so that not too many documents end up in the same class.

JuNii2
JuNii2 is a de-facto standard of metadata schema for institutional repositories in Japan.

NIIType in JuNii2 corresponds to Genre in eSciDoc. I made a simple mapping between two types of categories. Some of NIIType are missing in Genre. The mapping table is as follows:

Note:
 * Missing types will be converted as "Others" type.
 * The genres marked as "×" cannot be used in the current PubMan service.

Question and comments: you mean a new label for "journal article" or a new genre type?--Ulla 16:20, 29 January 2009 (UTC) Masao 03:56, 21 January 2009 (UTC)
 * We would like to provide the JuNii2 set via OAI-PMH. Maybe we need to develop a configurations for OAI-set and the mapping above.
 * Is is possible to use "Article" in PubMan?
 * Report genre is a broader type than the types in NIIType (Technical Report and Research Paper). So it is difficult to determine these mappings automatically.
 * The following missing types will be useful as additional new genres in eSciDoc.
 * "Departmental Bulletin Paper" definition and useful description needed (example would be good, to clearly separate it from "series" and "working papers".)--Ulla 16:20, 29 January 2009 (UTC)
 * "Data or Dataset" we currently assume, that this is part of "supplementary material". We still do not know, if we need to further categorize the types of supplementary material.--Ulla 16:20, 29 January 2009 (UTC)
 * "Software" we currently assume, that this is part of "supplementary material". We still do not know, if we need to further categorize the types of supplementary material.--Ulla 16:20, 29 January 2009 (UTC)
 * "Research Paper" As Japanese definition, this definitely would be new genre, but maybe even part of "institutional activities". See more under institutional activities on PubMan--Ulla 16:21, 29 January 2009 (UTC)