The development of ONIX has followed a very different path to that of Dublin
Core. We're not trying to meet the needs of a large and varied community
concerned with resource discovery, for whom Dublin Core is ideal; but the
needs of a relatively small and well-defined community, which could be
termed "the publishing trade", that is concerned with the supply and sale of
published products. ONIX therefore enables detailed information about a
published product to be exchanged, some of which maps (in a non-trivial way)
to the bibliographic metadata elements of Dublin Core, but much of which is
not addressed by Dublin Core and deals with commercial issues such as price,
tax, distribution rights, promotional text and so on.
Many of the recipients of ONIX messages (e.g. libraries, bibliographic
agencies and online booksellers) will no doubt wish to generate Dublin Core
metadata from the relevant elements within an ONIX record. For them I
believe it is indeed important that there should be a clearly-defined
mapping from ONIX to Dublin Core (the mapping does not, in general, need to
be reversible). Who should be responsible for defining such a mapping? This
issue is not central to the concerns of either ONIX or Dublin Core, but in
my opinion it is important enough that there should be some attempt to agree
a resolution that suits both communities. As I have already said in the ONIX
discussion forum, I would be happy to contribute to the definition of such a
mapping. Substantial progress has already been made by Cliff Morgan as
recorded in his earlier posting to this list (see below).
Francis Cave
PS Although I am a member of the ONIX development team, the views expressed
above are my personal views and not the official position of any body
associated with the development or governance of ONIX.
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/
> -----Original Message-----
> From: The broadest of mailing lists related to the international Dublin
> Core effo [mailto:[log in to unmask]]On Behalf Of
> [log in to unmask]
> Sent: 02 January 2001 09:19
> To: [log in to unmask]
> Subject: Re: [Fwd: [ONIX_IMPLEMENT] Digest Number 48]
>
>
> It's not a question of "seeing no reason to coordinate [our] activities"
> but a realisation that the two metadata sets are trying to do different
> things. "The people who are working on the ONIX standard" and "[the people
> working on] the DC Initiative" is a false contrast - some of us are the
> same people.
>
> ONIX 1.3 will be a rich product metadata set for e-books. As I said in my
> posting, it would be easy to extract a reasonable DC record out of an ONIX
> record. DC is well-designed to cope with such a reductionist approach. But
> I think this is quite different from developing the ONIX standard as "a DC
> extension for the e-book community". Just compare the two tagsets:
> "extension" is rather underplaying it! It wouldn't be an extension so much
> as an application profile where DC tags would be sparse, or dumbed-down,
> compared with the ONIX ones.
>
>
> 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
>
>
>
> ******************************************************************
> *******************
>
>
>
>
>
> David Dorman <[log in to unmask]>@JISCMAIL.AC.UK> on
> 29/12/2000 18:00:51
>
> Please respond to David Dorman <[log in to unmask]>
>
> Sent by: The broadest of mailing lists related to the
> international Dublin
> Core effo <[log in to unmask]>
>
>
> To: [log in to unmask]
> cc:
> 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/
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
|