Data Format Issues and Ideas

Issues (cooked)

Issues (raw)

• Relationship to FRBR and RDA. Is this a time of change that requires a new format, or should these be treated as separate needs?
• Can we tackle just MARC bibliographic, or do we also need to include at least Authorities and Holdings in our analysis?
• MARC causes library data to be marginalized (but MODS, a friendlier XML format, hasn't had much more success at crossing over to other fields)
• How do you express the current table of contents RSS feed for a journal title from CiteULike?
• There are a lot of advantages to MARC. We have a lot of data in MARC. It would be expensive to move whole hog off of it. Maybe we keep MARC for some bibliographic data.
• MARC has many fields and data elements (fixed) that can no longer be expanded, so new data elements cannot be added.
• MARC Bibliographic is not just bibliographic -- there is info for ordering, URLs to related web items, holdings info...
• What fixed fields are used by systems? What need is there to carry this information into a new data format?
• social tagging -- can it work?
• Browsing -- a requirement of the data format, or a system feature, or not needed (because it would be better to use topic maps)?
• Need to list problem data elements, i.e. dates (some ambiguity), genres (see MODS)

• Examine the results of the data analysis done by Moen for 007 field in particular. Suspect that few vendors do anything with many of the elements defined in the 007. This could be an interesting place to experiment with: if there is very little legacy data there in the first place (check Moen's results); and second, for the legacy data that IS there, if no one is using the majority of the data elements (i.e., end-user retrieving or browsing in a meaningful way, not simply encoding on the creator side); then, maybe it would be fertile ground to consider 'lifting' (liberating) this part of the construct and remodeling this portion elsewhere.