Talk:PubMan Func Spec Submission/BioMed Central Mapping

BioMed Central Elements Mapping
Handling identifiers: Somehow I don't like the idea of handling identifier types heterogeneously within PubMan, i.e. sometimes the type is specified explicitly, but sometimes it is just added as a prefix to the identifier value. I would suggest to register those identifiers as new types which are well understood and generic (e.g. pubmed - which is probably the PMID - and pii) - and not to map other identifiers at all. --Inga 21:49, 10 March 2009 (UTC)

BTW: Is there any need to store the identifier of the original metadata record in any specific way? --Inga 21:49, 10 March 2009 (UTC)


 * We had this discussion last time with the PubMed Mapping and it was discarded by FUNC and DEV team to introduce new types for all new identifiers we are fetching. Actually this is a quite more complex issue which was already discussed, but can not be implemented with next release.--Friederike 08:09, 11 March 2009 (UTC)


 * But PMID/PII are no origin identifiers in this case, right? PMID in particular developed to a de-facto standard over the last years and is often added to non-Pubmed records as well. --Inga 13:00, 11 March 2009 (UTC)
 * Ahhh... was not aware of that, thanks! I will discuss with Natasa and Nicole to integrate identifier type PMID and PII

Dates: What is the difference between ArticleSet.Article.History.PubDate.Year ArticleSet.Article.Journal.PubDate.Year ... and do we really need both? --Inga 21:59, 10 March 2009 (UTC)
 * The dates are destinguished by the attribute pubStatus, as far as i know, the Journal date only contains 'official' publishing (print or online) date. In the history we can have more info about the 'process' of the item, like accepted, revised etc. as we can map the information to escidoc, why should we not?--Friederike 08:31, 11 March 2009 (UTC)

Group: Have you found any example/specification which motivates mapping ArticleSet.Article.GroupList.Group.* to Publication.Creator.Person.* instead of Publication.Creator.Organization.* ? --Inga 21:59, 10 March 2009 (UTC)


 * That was what i thought first, as well, but a Group can also have an affiliation which we could not map if we map the name to Publication.Creator.Organization. Actually we can not model groups in escidoc, therefor I thought this would be the best mapping.--Friederike 08:06, 11 March 2009 (UTC)
 * Could you provide us with an example for usage of GROUP container though? --Inga 12:58, 11 March 2009 (UTC)

As, even after intensive search, i could not find any example of a author.group, this field will not be mapped.--Friederike 14:18, 11 March 2009 (UTC)