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/
________________________________________________________________________
________________________________________________________________________
|
