A few comments on these messages concerning the OEB Publication Structure
and Dublin Core.
I was recently added to the OEB Publication Structure Working Group
(OEBPS) and tried to advise them on their use of Dublin Core in the
current version of OEBPS. They refer to DC 1.0 in that standard, and I
advised them to use 1.1, but they were worried about existing data and
didn't want to make changes. However, they are now working on version 2.
A new working group on metadata was established as part of the Open Ebook
Forum, which will look at various metadata schemes and make a
recommendation; it is most likely that the metadata piece will be outside
of the OEBPS document itself in the future (except for existing data that
uses the earlier OEBPS specification). Although many people are expecting
an endorsement of ONIX (probably primarily because of the AAP proposed
metadata standard for ebooks, which recommends ONIX with some new
elements), this is not a fait accompli. The new working group was told to
critically evaluate the AAP proposal.
The new OEB Metadata Working Group was established at the OEB Summit in
December in Denver; it will have a meeting on Jan. 12th at the Library of
Congress. I am vice-chair of the group; Liisa McCloy-Kelley of Random
House is chair. I did intend to suggest doing a mapping between ONIX and
Dublin Core if ONIX is endorsed as the metadata format. But whether that
will happen is not yet clear.
The Library of Congress has recently put up a mapping between ONIX and
MARC 21. It can be found at:
http://lcweb.loc.gov/marc/onix2marc.html
LC is working with Editeur to improve the convergence between the two
metadata schemes.
Yes, there are always problems mapping a simple scheme with a more complex
one. I haven't studied the relationship between ONIX and DC
thoroughly; thanks for doing this, Cliff. I will say that in the AAP
recommendation, it is acknowledged that ONIX needs some extensions to deal
with electronic resources, particularly in the area of format.
It is appropriate for the OEB metadata group to seriously consider how
Dublin Core can be mapped to whatever scheme is endorsed (if other than
Dublin Core), since the OEBPS does use it. That is work that will need to
be done as part of this effort.
Rebecca
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^ Rebecca S. Guenther ^^
^^ Senior Networking and Standards Specialist ^^
^^ Network Development and MARC Standards Office ^^
^^ 1st and Independence Ave. SE ^^
^^ Library of Congress ^^
^^ Washington, DC 20540-4402 ^^
^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^
^^ [log in to unmask] ^^
^^ ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Date: Fri, 29 Dec 2000 12:00:51 -0600
> From: David Dorman <[log in to unmask]>
> Subject: [Fwd: [ONIX_IMPLEMENT] Digest Number 48]
>
> I thought this post would be of interest--and concern--to the DC
> community. Apparently, the people who are working on the ONIX standard
> see no reason to coordinate their efforts with the DC Initiative. It
> seems to me that the ONIX standard could appropriately be developed as a
> DC extension for the ebook community, but that opportunity will be lost
> if the two communities do not coordinate their efforts.
>
> David
>
> -------- Original Message --------
> Subject: [ONIX_IMPLEMENT] Digest Number 48
> Date: 29 Dec 2000 16:09:29 -0000
> From: [log in to unmask]
> Reply-To: [log in to unmask]
> To: [log in to unmask]
>
> -------------------------- eGroups Sponsor -------------------------~-~>
> eGroups eLerts
> It's Easy. It's Fun. Best of All, it's Free!
> http://click.egroups.com/1/9698/0/_/_/_/978106169/
> ---------------------------------------------------------------------_->
>
> To unsubscribe from this group, send an email to:
> [log in to unmask]
>
>
> ------------------------------------------------------------------------
>
> There are 2 messages in this issue.
>
> Topics in this digest:
>
> 1. Re: Relation of ONIX to the Open Ebook Standard and the Dublin
> Core
> From: [log in to unmask]
> 2. RE: Relation of ONIX to the Open Ebook Standard and the Dublin
> Core
> From: "Francis Cave" <[log in to unmask]>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 1
> Date: Thu, 28 Dec 2000 16:26:32 +0000
> From: [log in to unmask]
> Subject: Re: Relation of ONIX to the Open Ebook Standard and the Dublin
> Core
>
>
> I think Francis's reply gave a very clear picture of the relation
> between
> ONIX and OEB. My own view is that OEB suffers from a bit of
> bandwagoning.
> They fell for Dublin Core before DC was standardized (and in so doing
> made
> assumptions about qualifiers that never came to pass), and now that they
> realise that DC (as a minimalist, resource-discovery-oriented metadata
> set)
> is unfulfilling, they've cast about themselves and plumped for a nice
> rich,
> product metadata set, i.e. ONIX, instead.
>
> Certainly it is rumoured that the next release of the OEB specification
> will go for ONIX over DC, but I would guess that this will be a subset
> of
> ONIX 1.3 (which has not yet been released).
>
> As far as current mapping goes, Alan Danskin of the British Library has
> also done an ONIX to MARC mapping, but in his case to UNIMARC rather
> than
> MARC21. I've not seen an ONIX to DC mapping. Francis suggested that I
> might
> be able to do one because he has seen work that I have done within Wiley
> where I have mapped our digital archive metadata set to both DC and OEB.
>
> I think the problem with trying to map DC to ONIX is that, at the high
> level, DC is too imprecise for ONIX. For example, the data element level
> dc:identifier doesn't in itself map to a general ONIX identifier tag.
> What
> you have in ONIX are three specific identifier tags in Level 1 (ISBN,
> EAN,
> UPC), or six in Level 2 (ISBN, EAN, UPC, publisher's product number,
> ISMN,
> DOI). So, you can't really map dc:identifier as a general tag to any of
> these, but you *can* map various instances of dc:identifier to
> individual
> tags, e.g. dc:identifier = 0471939900 would map to ONIX tag <b004> =
> ISBN.
>
> Some DC tags map neatly to ONIX, e.g.:
>
> (note: in these examples, I give the DC tag first, then the
> (non-mnemonic)
> ONIX short tag, followed by the ONIX XML Reference Name)
>
> dc:title = <b028> = <DistinctiveTitle>
> dc:description = <d101> = <MainDescription>
> dc:publisher = <b081> = <PublisherName>
> dc:date.issued = <b003> = <PublicationDate>
> dc:language = <b059> = <LanguageOfText>
>
> This leaves the following:
>
> dc:creator and dc:contributor - both map to ONIX <contributor> <b036>
> (= <Contributor> <PersonName>) but you need more information in ONIX in
> the
> form of <b035> = <ContributorRole>, which relates to a lengthy
> contributor
> role code list. For example, if dc:creator refers to the author of a
> book,
> this is equivalent to Contributor Role Code = A01; the editor of a book
> is
> B01; the translator is B06; and so on. So the mapping depends upon whom
> is
> being referred to in dc:creator or dc:contributor.
>
> dc:subject mapping depends upon which subject classification scheme is
> being used (BASIC subject categories map to <b064> = <BASICMainSubject>;
> BIC subject categories map to <b066> = <BICMainSubject>; using other
> classification schemes maps to a range of codes where the alternative
> scheme is identified as well as the subject codes themselves).
>
> dc:type doesn't really map to anything in ONIX. The current types listed
> in
> the DCMI Type Vocabulary are very basic (collection, dataset, event,
> image,
> interactive resource, service, software, sound, and text - see
> http://purl.org/dc/documents/dcmi-type-vocabulary for definitions of
> these
> terms).
>
> dc:format doesn't map well either. ONIX format codes (such as <d103>
> = <TextFormat> or <f111> = <CoverImageFormatCode>) are more to do with
> the
> format of descriptive text or cover image than the format of the content
> being described.
>
> I don't think dc:source, dc:relation or dc:coverage map to ONIX at all.
>
> Finally, dc:rights would map to <b087> = <CopyrightYear> if that was the
> information contained within the DC tag, or it might map to the ONIX
> <rights> composite. But in general, dc:rights is a fairly unstructured
> beast that probably won't map too well.
>
> ****************************
>
> So that's my initial view on the DC to ONIX mapping possibilities - they
> don't map too well because they are coming at resource/product
> description
> from quite different directions. (It's the old minimalist vs
> structuralist
> dichotomy yet again!) And personally, I think there's no way that ONIX
> should be defined as an extension to Dublin Core - they're not trying to
> do
> the same thing. You could build an application profile whereby an ONIX
> record could have the relevant elements extracted to make a DC record,
> but
> trading down is always easier than trading up.
>
> I'd be grateful if any ONIX-savvier people than me could point out if
> I've
> made any errors in this first pass.
>
> Regards
>
>
> Cliff Morgan
>
>
>
> *************************************************************************************
>
>
>
> Publishing Technologies Director Tel (+44) 1243 770440
>
> John Wiley & Sons Ltd
>
> Baffins Lane Fax (+44) 1243 770 460
>
> Chichester
>
> PO19 1UD [log in to unmask]
>
> UK
>
>
>
> *************************************************************************************
>
>
>
>
>
> [log in to unmask] on 23/12/2000 16:33:32
>
> Please respond to [log in to unmask]
>
> To: [log in to unmask]
> cc:
> Subject: [ONIX_IMPLEMENT] Relation of ONIX to the Open Ebook Standard
> and
> the Dublin Core
>
>
> I would appreciate a general overview of the relationship between the
> ONIX XML DTD and the Open Ebook Standard. My sense is that the Open
> Ebook Standard is a framework within which the ONIX DTD would be used.
> Could anyone confirm (or correct) this understanding?
>
> Also, I saw that someone at OCLC has mapped ONIX to MARC21. Has
> anyone mapped ONIX to the Dublin Core or tried to formally define
> ONIX as an extension of the Dublin Core?
>
> Thanks for considering this request for information.
>
> David
>
> David Dorman
> Consultant, Lincoln Trail Libraries System
> Contributing Editor, American Libraries
> Urbana, Illinois
> 217-352-0047
>
>
>
> To unsubscribe from this group, send an email to:
> [log in to unmask]
>
>
>
>
>
>
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 2
> Date: Fri, 29 Dec 2000 00:31:58 -0000
> From: "Francis Cave" <[log in to unmask]>
> Subject: RE: Relation of ONIX to the Open Ebook Standard and the Dublin
> Core
>
> I'm grateful to Cliff Morgan for following up my posting with such a
> detailed response!
>
> > dc:format doesn't map well either. ONIX format codes (such as <d103>
> > = <TextFormat> or <f111> = <CoverImageFormatCode>) are more to do with the
> > format of descriptive text or cover image than the format of the content
> > being described.
>
> The eBook extensions in Release 1.3 of ONIX will probably include new
> data
> elements that will enable the specific format(s) of an eBook to be
> specified. I believe that's as close as ONIX will get to dc:format.
>
> > I don't think dc:source, dc:relation or dc:coverage map to ONIX at all.
>
> Release 1.3 will also probably introduce a new composite for specifying
> "related works" from which the product being described has been derived.
> I
> believe this will correlate in part with dc:source.
>
> There is no direct equivalent of dc:relation, but some uses of this may
> correspond (in a non-trivial way) with uses of ONIX composite elements
> <RelatedProduct>, <ContainedItem>, <Set> or <Series>, and with a
> proposed
> new composite in Release 1.3. for specifying "included content".
>
> The ONIX element <PlaceAsSubject> would appear to map to the
> geographical
> uses of dc:coverage. Temporal uses of dc:coverage may partially
> correspond
> to uses of the <Subject> composite where the value of
> <SubjectSchemeIdentifier> indicates that the value of <SubjectCode> is a
> time period - at present the only scheme available is the "BIC time
> period
> qualifier" (scheme identifier value "15").
>
> Francis
>
>
>
> Francis Cave Digital Publishing
> The Old Bakery
> Felday Glade
> Holmbury St Mary
> Dorking
> Surrey RH5 6PG
> United Kingdom
> Tel/Fax: +44 1306 731655
> Email: [log in to unmask]
> Web URL: http://www.franciscave.com/
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> ------------------------------
>
> End of DC-GENERAL Digest - 28 Dec 2000 to 29 Dec 2000 (#2000-15)
> ****************************************************************
>
|
