[openbiblio-dev] Bibliographic Metadata Guide is now on Wiki !

Tue Nov 8 20:08:30 UTC 2011

Quoting Jim Pitman <pitman at stat.Berkeley.EDU>:

>
>> All, do you think the list of minimum metadata elements for literary works
>> is sufficiently accurate & detailed ? Shall we move on to different  
>> types of works? e.g. images, movies, sounds ?
>
> I would stay away from these difficult and complex data types for  
> now, and focus on end-to-end delivery of
> metadata from book and journal data sources to naive users for some  
> significant book collections.

I agree with Jim. In in the spirit of incremental development it would  
be best to get some experience with the book and journal article data  
before moving on.

> There is the issue of exactly how/where these  
> optional/recommended/.... R/NR fit relative to the BibJSON spec. I  
> think
> they are something like an "application profile" relative to DC.

Yes, and DCMI is starting up a second round of work on the application  
profiles with the goal of getting a good, re-usable data structure.

Constraints on cardinality should not be part of the definition of  
data elements but instead should be related to an application. For  
example, some systems may need to limit the number of authors for  
purely practical reasons. (I worked on a system that limited to 99  
authors, and some articles -- few but some -- would have exceeded that  
limit.) That wouldn't make their data incompatible with that of others.

I have to say that I truly admire the REPEC approach, with good  
guidance on what the data elements mean, and then templates for  
filling them in. If the templates could be driven by schemas, then  
users could work within the constraints of their systems.

I believe we already talked about having a very, very limited number  
of required data elements -- essentially only those absolutely  
necessary to process the data (plus one or two bibliographic fields --  
title seems essential).

kc

> The application we have in mind is a typical cataloger or publisher
> opening up their metadata. But we have yet to formalize this. In any  
> case, it seems from
> the perspective of general BibServer dev, that these attributes  
> (except maybe R/NR) should not be built into the BibJSON spec,
> but kept somehow separate. Thoughts about how to manage this?
>
>
> --Jim
>
>> >
>> > I added a few points too. I'm not clear on the relation of this  
>> etherpad to
>> > Primavera's very professional looking  Wiki setup.
>> > The structure of this page parallels closely the structure of e.g.
>> > http://en.wikipedia.org/wiki/BibTeX
>> > especially with respect to the required/optional nature of the elements
>> > associated with various
>> > types of document.
>> >
>> > These elements should be defined independent of type, to the greatest
>> > extent possible, though often
>> > meanings are understood by type, e.g. the ISBN field of a book chapter is
>> > an identifier of the book not the chapter.
>> >
>> > It is a question where exactly do the declarations:
>> >
>> > O - optional
>> > MA - mandatory if applicable, but may be legitimately missing
>> > M - Mandatory
>> > R - repeatable
>> > NR - not repeatable
>> >
>> > live relative to e.g. a JSON or XML schema that defines what machines can
>> > make of such data.
>> > The R/NR classification is structural, and likely part of the schema.  A
>> > metadata doc which did not meet the
>> > R/NR requirements would be invalid.  The O/MA/M status is not structural,
>> > but part of some best practice. Machines should help us deal
>> > with bad practice.
>> > I think main thing is that when data providers offer to publish metdata we
>> > give them a way to easily express all that they have,
>> > without undue burden.  I would be inclined to drop the M word, and go with
>> > "recommended" or "strongly recommended" for most elements
>> > presently marked as M.
>> >
>> >
>> > --Jim
>> >
>> > ----------------------------------------------
>> > Jim Pitman
>> > Professor of Statistics and Mathematics
>> > University of California
>> > 367 Evans Hall # 3860
>> > Berkeley, CA 94720-3860
>> >
>> > ph: 510-642-9970  fax: 510-642-7892
>> > e-mail: pitman at stat.berkeley.edu
>> > URL: http://www.stat.berkeley.edu/users/pitman
>> >
>

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