However, since I recently have undertaken to redesign some of my personal web properties such as FreeLargePhotos.com and SonomaValleyWineries.org, I took that as an opportunity to finally integrate Schema.org markup into my pages. In so doing I found some tools that helped me to do it that I want to highlight for anyone trying to do the same.

To make it easy to find out what markup you should put where, Google offers the Structured Data Markup Helper. First you select the type of item you wish to markup from one of these:

• Article
• Movie
• Software Application
• Event
• Product
• TV Episode
• Local Business
• Restaurant

Then you plug in the URL of one of your representative pages (for me that was a descriptive page for a winery) and hit the “Start Tagging” button. The site then loads the page and allows you to highlight representative strings of text on you page and select what that string is from the options — things like “name” or “phone” or “email”. The options are defined by the type of item you selected at that start, so it only allows you to pick relevant labels.

After marking and labeling all of the relevant metadata elements, you hit the “Create HTML” button and it shows you your HTML markup with the embedded Schema.org markup highlighted. This shows you exactly what you need to do to add structured metadata to your pages.

After you’ve done that, you can then use another one of Google’s tools to verify that it worked. Go to Google’s Structured Data Testing Tool and plug in the URL of one of your pages. It will attempt to scrape the embedded metadata from your page and show you what it has extracted. If you don’t see what you expect then you may have to fix an error. Otherwise, you’re good to go.

The likely benefits are two-fold. One is that Google and other search engines can display more full-featured and accurate descriptions of individual search results that have such markup. Another is that search engines may give results that have such markup more “juice” in results ranking. In other words, it is very likely to be worth the little effort it might take to embed this markup in your pages. And if your pages are generated by a CGI script as mine are, then there is very little excuse not to.

As you might imagine, doing this well requires both intimate knowledge of the data being captured in the various standards and a very detailed and painstaking process of determining where those elements need to end up — and how. Therefore, the issues below are often quite specific and backed up with evidence.

• Some critical information is represented redundantly. Example: A description of an e-book is spread across the 245, 008, and 300 fields, but is concisely represented in a more modern standard such as ONIX. 
• Some MARC fields are ambiguous. Example: The MARC 300 field has an ‘extent’ sense when it appears in a record that describes a sound recording. But it has a ‘page count’ sense in a record that describes a printed book. The Crosswalk has to make an unreliable check for data in a free-text field to disambiguate the two senses. When distinctions exist in 5xx fields, they may not be recoverable at all. 
• Many MARC free-text fields have formatting requirements. Example: ISBD formatting rules for titles require that only the first word be capitalized. Since this convention is not widely used outside the library community, it must be taken out when a MARC record is translated to a non-MARC standard. 
• Punctuation in free-text fields is sometimes meaningful, sometimes not. Example: In a 100 field, the comma separates parts of a structured name and indicates an inverted presentation order. In a 500 field, the comma is just another character in a stream of text. 
• Some MARC fields are coded with hidden assumptions. Example: A MARC record that describes the author of a printed book has no explicit mention of the author’s role or the physical format of the work. But a MARC record that describes a musical score identifies the material type in a code in the 008 field and the contributor’s role in a $4 field. 
•  MARC data elements are semantically complex and built up from many components. In most contemporary non-MARC standards, the elements are semantically simpler and resemble the words in a dictionary that make up a bibliographic description, such as title, contributor, personal name, and subject. Example: Marc 245 $a is not a title. It is an AACR2-defined access point that may contain a concise bibliographic description with title, author, author’s role, physical description, producing another one-to-many mapping. 
• MARC has a “long tail.” In other words, the standard is large, but MARC tag usage studies (1, 2) show that most of the specification is rarely used. In fact, many of the most widely used fields are the 5xx notes, despite many opportunities for representing a description in more explicitly coded data. This can be interpreted as evidence that MARC is no longer the best fit for bibliographic data, perhaps because new concepts are not represented and some existing concepts are not modeled effectively.

However, as I turn to identifying specific problems that I and other see with our present situation, I should take pains to point out that I am mostly referring to the MARC21/AACR2/ISBD formulation that has held North America in its sway for lo these many years.

Also, it became clear that I as I shared a draft with colleagues that I had enough to work with that I should break it into two parts — this first part are largely the things that I see as problems and the second part will be things that my colleague Jean Godby has identified as specific issues discovered from her voluminous and thorough work at crosswalking MARC21 to ONIX and other formats and vice versa.

So with that, let’s get started, and in no particular order:

• Needless complexity. Over the forty or so years that MARC has been around, it has accreted many fields and/or subfields. Some of these are veryinfrequentlyused and yet they remain part of the standard. This means that any software written to produce or process MARC records must accommodate fields and/or subfields that hardly anyone uses. Such complexity comes at a cost that is not always justified.
• Over-reliance on punctuation for semantic purposes. Punctuation marks are used in MARC for display purposes or for indicating different elements (that is, for enhancing granularity). For example, commas, slashes, and colons often appear to indicate separate elements and yet those marks can damage the ability to unambiguously parse the elements for purposes other than simple display.
• Lack of sufficient granularity. For example, the 100 field where a personal name is recorded relies upon the placement of a comma to delineate parts of a name. This prevents, for example, the delineation of the male and female surnames for the names of Spanish creators (order can no longer be assumed to be male-female as it might have been in the past).
• Lack of standardized statements/declarations when those would be useful. One of the most basic things a library use expects to be able to do is to identify content that is fully digital and openly available, and yet we have no way to unambiguously state this using MARC (see, for example, “MARC and the Trouble with Online”, http://www.infodocket.com/2013/03/05/slide-presentation-roy-tennant-on-marc-and-the-trouble-with-online-or-metadata-carnage-and-where-we-go-from-here/ )
• Inability to unambiguously encode important characteristics. We presently have hundreds of ways that we attempt to encode the concept that a given URL in an 856 field will lead the user to the full item online. This is because we have no unambiguous way to encode this information. Neither do we have an unambiguous way to encode the information that an item is open access. Both of these are extremely valuable aspects of our bibliographic data that users rightly expect us to be able to provide.
• Lack of easy extensibility. MARC lacks the ability of a given community (for example, archivists) to specify their own set of descriptive elements that could either be processed or ignored by consumers of MARC given their needs. Rather, even the most minor of changes must be vetted through a time-consuming process to eventually be added to a standard where every element has equal weight to every other element (see “Needless complexity” above).
• Technical marginalization. The only users of MARC are libraries, and to a much lesser degree, publishers. Meanwhile, the publishing community has created its own standard, ONIX, which will likely marginalize MARC even further in the bibliographic metadata world. MARC itself is anachronistic as a computer communication standard, since to have even the remotest chance of understanding it requires reference to documentation that identifies the purpose of – for example – every byte in the header. And yet our complete reliance on a single record format means we are ill-equipped to deal with anything else.

Those are just some of the issues that occur to me as I think about where we are now and where we need to be. I would be interested to hear your thoughts — whether for or against — in the comments below.

But for the rest of us it’s a disaster. This is why.

Those of us who don’t have an employer to buy the software are usually hobbyists or freelancers. We might be a hobby photographer who appreciates the power of Photoshop to make our photos look their best. Or a starving artist using InDesign to do flyer or poster design on the side. For folks like us we would typically buy a copy of the program we couldn’t do without and then wait for a couple updated releases to pass before catching up again. The thing is, we could barely afford it to begin with, and now they want to charge us a monthly rental fee? It’s not happening.

At $20/month for one application, that means you would spend around $240 a year. Not $240 every once in a while, but yearly. Constantly. Forever until the end of time. Or until you died or stopped using the software, whichever came first.

For we librarians, this refrain is all too familiar. First it was e-journals, then e-books that we were forced to rent, not buy. As soon as we stop paying we have nothing, so we pay and we pay. Well, I’m not buying it — literally and figuratively.

Now before someone comments that I’ve said good things about cloud computing in the past, so what’s up with this screed against it — I’ve always said that cloud computing can make a great deal of sense for certain situations and applications. I just don’t happen to think that the situation described above is a good one for me or others like me. And apparently we will not be offered a choice in the matter.

Please note: This series of posts outlines my opinions and does not necessarily reflect the opinions of my OCLC colleagues or of OCLC as an organization. Also, these opinions are held regardless of any impact the paths I suggest may have on my employer.

You will not be able to stay home, brother.
You will not be able to plug in, turn on and cop out.
You will not be able to lose yourself on skag and skip,
Skip out for beer during commercials,
Because the revolution will not be televised.
…
The revolution will not be televised, will not be televised,
will not be televised, will not be televised.
The revolution will be no re-run brothers;
The revolution will be live. — Gil Scott-Heron, “The Revolution Will Not Be Televised”

Over a decade ago I wrote two columns entitled “MARC Must Die” and “MARC Exit Strategies” for Library Journal. Although provocative at the time, it now appears to be accepted wisdom that we cannot carry on as we have. A major example of this are the Library of Congress’ Working Group on the Future of Bibliographic Control and the Bibliographic Framework Initiative (BIBFRAME for short) that emerged from that work.

Their statement about the BIBFRAME work reads, in part:

The Library of Congress has launched a review of the bibliographic framework to better accommodate future needs. A major focus of the initiative will be to determine a transition path for the MARC 21 exchange format in order to reap the benefits of newer technology while preserving a robust data exchange that has supported resource sharing and cataloging cost savings in recent decades.

Meanwhile, the National Information Standards Organization (NISO) has not been sitting on its hands. It received a grant from the Andrew W. Mellon Foundation to “support an initiative to develop a community roadmap that will help support movement toward a future bibliographic information exchange ecosystem. The goal of this project is to collectively determine the needs and requirements of the library, higher education, and non-profit networked information communities to ensure they are able to use and exchange bibliographic data in an increasingly networked, linked data environment.” To accomplish this, NISO is organizing a number of meetings (mostly virtual) this year. The first and only planned in-person meeting was just held.

So for the last couple of days I attended virtually as much as I could of the NISO Bibliographic Roadmap meeting held in Baltimore, MD. Their description of the event:

NISO will host a two-day “unconference” to brainstorm and explore topics that will be a core component of the overall roadmap that NISO is working with the library, higher education, and non-profit networked information community to formulate. The goal of this meeting is to engage participants in an open conversation about the future of our collective bibliographic exchange ecosystem.

I ended the event not feeling much more enlightened or inspired than I began, and I’m afraid that this experience may have been shared by not a small number of those in the room. That got me to wondering why. Partly I think it was so all over the map because there was no shared clarity on the problems that need fixing and a lack of agreement about which paths might best solve those problems. For the most part, people left with the personal agendas they arrived with — some of them quite strongly held.

It was then that I remembered Gil Scott-Heron’s message to his black brothers and sisters back in the day. The revolution will be live. It can’t be packaged up and delivered to your computer or TV set so you can passively consume it from the comfort of your couch. It won’t be led and controlled by the few. It won’t be packaged nicely for your consumption. It will be messy, difficult, frustrating, and uncertain. It will be impossible to predict and may only make any kind of sense in hindsight. And it will require your participation.

So for my part I resolved to think more about those issues and write about them here. This is the first of a series of posts in which I will endeavor to put down my best thinking about the subject, which means you may want to lower your expectations now.

Watching the NISO event over the last two days crystallized for me that I had fallen into the trap of thinking that the Library of Congress or NISO or OCLC (my employer) would come along and save us all. I forgot that for a revolution to occur it can’t come from the seats of the existing power structure. True change only happens when everyone is involved. Those organizations may implement and support what the changes that the revolution produces, but anything dictated from on high will not be a revolution. The revolution will not be piped into our cubicles, ready for easy consumption. The revolution will be live. 

Photo by Franco Folini, Creative Commons Attribution-ShareAlike 2.0 Generic license.

Your best strategy when making a plan is to make contingency plans for the inevitable result that life will not unfold according to plan. Herewith are some thoughts on what you might want to do:

• Expect the unexpected. I realize it is a cliché, but it remains true. I don’t mean you must be prepared for every eventuality, but you should expect to be surprised. Know that your plan will not unfold as you expect, so you can be not only prepared for the variances, but you can see them coming.
• Schedule reassessments. If you know that changes to your plan are inevitable, it is best to seek them out. Place points in your plan to do this. Otherwise, you run the risk of speeding past the points when a course correction could have prevented disaster.
• Solicit outside opinions. You, or your team, are not always the best judges of when course corrections are needed. Seek outside counsel.
• Underpromise. I know that the phrase is usually “underpromise and overdeliver”, but frankly I think the “overdeliver” part is mostly wishful thinking. Given how most of us plan, we tend to think we can accomplish more than we really can, so if we underpromise (in our opinion at least) we are more likely to simply come in on target when things inevitably don’t go as planned.

There are likely more strategies that I haven’t thought of, but I bet you have. Please comment below if you think of something.

Photo by ER24 EMS, Creative Commons Attribution-ShareAlike 2.0 Generic License

So not only do I need to give up just about everything (did they leave anything out?) about me, I have to give up my friends and everything about them as well. Since when did this ever — even remotely — become OK?

I did not click “Okay”. You can thank me later, my friends.

But I find this really, really disturbing when the simple act of “friending” someone on a site like Facebook allows you to lose control of your information to everyone you’ve ever friended.

This prompted me to investigate what setting in Facebook I could change to make sure others weren’t inadvertently or even on purpose sharing my data with others without my knowledge. I found a page on Facebook that appeared to explain (even with an illustration) how to control this:

But I could never find this. Also, note how the only way to not give up your friends is to turn off the Facebook Platform entirely, which of course shuts down your ability to use Facebook to login to other sites as well as any apps or games you use on Facebook. In other words, we’re toast people.

If you use Facebook, you can forget about privacy. Just forget about it. Even if you think you are controlling it, you must trust that all of your friends — ALL of them — are not going give you up when they very likely already have.

I’m not writing to argue the relative merits of the case, which others who are much better qualified have done, but merely to point out an odd sideshow (among several, it must be acknowledged, including letters sent to the Scholarly Kitchen; also, look up their office addresses in Google Maps). It is this: The Edwin Mellen Press has registered domain names using Dale Askey’s name. Here is the evidence.

The registration record for DaleAskey.com:

The record for DaleAskey.net:

The (very) thinly obfuscated identity is kind of a nice touch. And since if you attempt to go to http://daleaskey.net/ you are redirected to http://daleaskey.org/, here is the record for .org, which you will see has been privately registered:

What does this all mean? I really don’t know, and I will not speculate. I am just reporting it. Also, a shout-out to Andy Woodworth, who first brought this to my attention.

Update: Andy reports that the credit really belongs to Christa Burns – sorry Christa! I had heard it via Andy.

Why would Amazon want to keep three different sites going that offer basically the same kind of service? Sure, what they really want is the user data — but why pay top dollar to get it by keeping three independent efforts going? Why indeed.

Jeff Bezos hasn’t gotten where he is by being a bad businesman, so my money is on a shakeout ahead. GoodReads appears to be winning the war of popularity in this space, according to Alexa Rank, so the smart money would be on GoodReads swallowing up Shelfari in a merger to gain the cost savings. LibraryThing is a bit more complex, as Amazon does not (yet) have a majority stake. Amazon could either let them keep going while siphoning user data out the back end, or it could make a play to grab it all. Whatever happens, I think the next few years will be interesting in this space.

Your own speculations are welcome in the comments.

Those were heady days. Something new was coming along all the time, and the frontiers for learning stretched out to the distant horizon. There were LISTSERVs and Usenet Newsgroups, Archie, Gopher, Veronica, WAIS, and who knows what else. It was the digital wild, wild west and new cowpokes were coming to town at the same time that others were getting gunned down in the streets. You never knew what tomorrow would bring.

That is, until NCSA Mosaic. With the release of the first graphical World Wide Web browser we all knew that everything had changed. It would no longer be the wild west because the Sheriff had pulled into town. Gopher suddenly looked…boring. Colorless. Un-engaging. Dead. Sure, it would take years to completely die, but it was all over except the procession.

And I happened to be there, with my colleagues Anne Lipow and John Ober, to record it for librarians in a way they could learn these new technologies and teach them to others. I remain proud of what we accomplished back then.

But whatever. Today I can no longer deny that I’ve been writing books about library technology long enough to be weeded. Color me old and nostalgic.