Re: ONIX data (moving into how it is used)

Quoting Daniel CannCasciato <Daniel.CannCasciato_at_CWU.EDU>:


>
> I don't buy (completely) the idea that data and presentation are  
> entirely different considerations. The recent discussion on this  
> list of our bibliographic data and what can be done with shows that  
> the two are inevitably linked. I understand that storage,  
> communication, and display are separate issues. But content quality  
> is linked to display potential.
>

Maybe we need to qualify this a bit. For textual data, the data and  
the display are very much linked, unless you do some fancy algorithmic  
footwork. So if your pagination is a text string:
    xii, 356 pages
that's basically what you will display. But if your pagination is "data-fied":

First pagination:
   format: roman numerals
   value: xii
   total: 12
second pagination:
   format: integer
   value: 356
   total: 356

then you have the option of displaying it in various ways:
   Total pages: 368
   Pages: xii, 356
   xii, 356 p.
   xii, 356 pagine
   Introductory matter: xii, numbered pages: 356

Any time you use an identifier for something from a list of values,  
you can have options for display. So if you use the VIAF identifier,  
you can choose a display that matches the desired value for the  
catalog of a chosen national library.

Or if you are using the identifier for one of the RDA content types,  
rather than its display form:

http://metadataregistry.org/concept/show/id/522.html

then currently you have the option of displaying that in English or  
German (and other languages can be added):

   spoken word
   gesprochenes Wort

This should be our main motivation for getting away from text wherever  
we can and moving to encoded data. It gives us more options for  
display and we should therefore be able to share data with other  
communities more easily. So if we could somehow incorporate publisher  
name data into VIAF, we could then take in publisher data but  
translate our display of names into the library equivalent.

The only fields that aren't amenable to this are the transcribed  
fields, but it should still be possible to create links between the  
library transcribed fields and equivalent texts from publishers -- in  
part by gathering up variant titles around ISBNs. (Yes, it will be  
imperfect. So is our data today. And there should always be room for  
human correcting of any machine-generated data. There, hopefully that  
cuts that objection off at the pass!)

Now obviously, bad data is bad data. But I think we were talking here  
not about bad data, which will always be a problem, but *different*  
good (good enough) data.

kc


-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet