Does your institution talk about managing non-MARC data? If it does, what does it mean to you? Shouldn't we talk about this data in more concrete terms?
Ed Summers
Phew. I think the answer to your question reflects organizational realities more than technological ones.
The libraries I've worked in had an entire department devoted to MARC cataloging. Anything else lived in the wainscoting -- the impoverished digital library, or the starved, staggering, scorned institutional repository. Whatever Those People Over There did, to a cataloger, was "non-MARC data," and you'd better believe it wasn't as important or as professional as MARC. Were Those People Over There even librarians? Some catalogers said not, frankly.
(There's a strain of rhetoric in the "whither libraries?" literature that bolsters this organizational dysfunction: it holds that MARC is one of librarianship's central mysteries, such that veering away from it means abandoning librarianship altogether. Michael Gorman and Martha Yee write in this mode, among others.)
The world is changing, of course. "Non-MARC data," even if we just consider it "library-created or library-held metadata in a form other than MARC," probably outweighs MARC data bit for bit by now. (This is a mildly unfair comparison, because MARC was designed for economy of storage, and XML was not. Even so.) Measuring by current-processing output, non-MARC data probably gives MARC a run for its money these days, considering how mainstream digitization has become, and how relatively simple and automatable it is to create much non-MARC data compared to MARC/AACR2/ISBD. (I grant you, PREMIS is a bear.)
But the linguistic markedness of MARC (see what I did there?) doesn't reflect production volume or holdings volume, much less a measure of impact on patrons or on the world. It reflects a MARC priesthood that still maintains considerable power over discourse within librarianship.
IMO, YMMV, etc.
Back when I was more active in them, the Koha and Evergreen communities routinely got questions about when those platforms were going to support "non-MARC" data. There were a few types of folks with these requests:
De facto catalogers who thought "MARC is too hard", by which they mostly meant "this cataloging interface sucks". They were rather correct. There should exist a cataloging interface that is intuitive enough to handle simple cases without the user knowing AACR or even that the system uses MARC internally (if it does). For example, something like Delicious Library 2.
Experienced catalogers or archivists who actually had specific formats in mind (e.g. DublinCore, EAD, RDA, etc.) or problems those formats are more tailored to address.
Early adopters of Koha who yearned for simpler times before MARC-centric code was introduced (pre-2.0, iirc).
The value of MARC is bibliographic data. MARC data is widely available for free (via z3950 or a web download), tools for manipulating it are widespread (often free), vendors can provide it, and any modern ILS can import it. No alternative format has comparable entrenchment.
The less bookcentric you are, the less you care about any of that. Arguably most libraries are finding themselves moving from more bookcentric to less, so this will keep coming up.
But to make any progress, yes, more concreteness is required. Crowdsourced tags are "non-MARC" data. LDIF is "non-MARC" data. EDI is "non-MARC data". OAI is "non-MARC" data. Etc., etc., etc....
I would guess that there is more non-MARC data at LC place of work than there is MARC data, if nothing else, because of TIFF images of newspapers take up a heck of a lot more space even than MARC-XML.
In academic libraries today, "working with non-MARC data" is frequently a very different beast than "working with MARC data". Different underlying technologies are involved, as well as different approaches to creating, maintaining, and reusing that data. The former is often a shorthand or code for an entire skillset and approach to work by the individual performing that work. That's been the case for the last 15 years or so, but it is changing. (And a welcome change at that.) As more and more individuals become versed in more and more methods of creating and processing data, we'll lose all of that implied baggage. And on a slower pace, as the balance of MARC to non-MARC metadata evens out a bit, we'll have to find better language for these things. I look forward to that day.
I agree with dsalo and Jenn Riley above but to address the last part of the OP's question---how we might talk about this in more concrete terms---there might be value in beginning to be more careful with our use of the terminology around MARC. "MARC" is a carrier/format, the content standards that govern what information gets conveyed around in MARC format are (usually) AACR2 /ISBD.
So, in the realm of other ways to talk about library data, we can talk about what information we record and how we serialize that data. Both are important discussions underway in library-land (as I know the OP and other commenters well know) and investing in the specifics of those discussions can be a helpful way to step over/around the unhelpful distinction between MARC and non-MARC.