Thoughts on learning objects

Many thanks to the Field Guide to Learning Objects and Tonya’s post on learning objects.

To me, the thing that makes learning objects new (or makes them useful) are:

  • Modularity.  The smaller the scope of the object, the more finely-tuned it is, then the more likely it is that someone can use it in their lessons.  This makes this different than, say, a textbook chapter.  I mean, we’ve all had assignments to read “Sections 1-4 of chapter 7” or, to be more lighted-hearted, have all of two weeks to read the high-school American-history chapters on “everything in the 20th century” because we spent a week on Jamestown.  Learning objects are designed to be accessible in bits and clumps and to be readily reviewed later in only the amounts needed.
  • Accessibility.  The metadata and technologies of learning objects seem best designed for permanent accessibility on the web.  If the object requires plugin downloads, that limits it.  If it’s not easy to see at a glance without opening the object how it will fit into a curriculum, that limits it.  If the metadata doesn’t fit with the developing standards out there for eventual depot collection, then that limits it.

It brings to mind two things.  One, the transition to linked data; in that we are looking for an authoritative, permanent accessible link to items on a concept or subject.  The second, Khan Academy, with its mini lessons, assessments, and community objects.

Another random thought: Web archives and searching are to librarians what learning objects are to teachers.  While a permanently accessible curriculum with no special “teacher’s edition” seems like an attempt to remove teachers from learning, it looks more like it’s removing the repetitive aspects of curriculum development and turning teachers into experts on tailoring curricula to their students.

Thoughts on learning objects

Version control: A primer

The Report from the DAM Foundation Universal Truth & Standards Commission from the DAM Foundation noted that a DAM solution must have version control, actual version control, and not just some method of keeping multiple copies of something.  But what exactly is version control, and why is it important to DAM and metadata librarians?

Well, first, the when-in-doubt article.  Revision control got its start in software development.  Software projects, even small ones, use a large number of files of multiple types and have many people working on them at once.  But let’s look at a much smaller, more immediate example.  Suppose you, a sales VP, have a presentation on Friday for your new product.  There’s a folder on the network with an image file, macguffin.jpg, holding a plain photograph of your product.  On Tuesday night, you make a copy of the file onto your thumb drive, take it home, and spend a couple of hours using photo editing to show the product sitting on a lovely granite counter top.  Wednesday morning, you bring the drive back and drop the image in, replacing the original.  On Thursday morning, you start making your presentation and drop the image in.  It’s not the image from yesterday; you know, because you didn’t use Blingee to make your image.  While you’re trying to figure out how you’ll explain the extra glitter to your client, your boss comes in and asks, “What’s up with macguffin.jpg?”

You reply, “I know!  I spent all of that time photoshopping it into a kitchen, and someone overwrote it.  We’ll need to see if there’s a backup of the network drive.”

He scowls, “Kitchen?  We need the plain photo for the patent applications!  Get the Monday backup first, then worry about your version.”

Version control software keeps track of changes to items.  It keeps them in a centralized location, from which you can check out items to work on using your local machine.  You can decide whether to check something out in such a way as to lock others out or not (usually not. Version control is great when many people need to work on something for a period of time).  You can refresh your local copy from the central location if you need to.  When it’s time to check back in, the central location lets you know if the version you checked out is no longer the same version that’s there now!  If there’s no conflict, the system lets you check in your new version, adding comments about what you changed, and keeping track of the changes made and who made it.

Thus, in your example, version control would have told you who made the Thursday version, it would have warned them that you had done work when they checked their version in (so they can’t say they didn’t know), and, most importantly, it has a simple command not only to change the file back to your version, but to any version (like the one your boss wants).  Complex version control would even let you create a “branch” version from the original “trunk”.  That way, the system would know that the two are related, and they can still be edited and versioned separately (or possibly merged someday).  So your boss can be happy, and you’d have your “presentation branch” ready for tomorrow’s presentation.

CEO got his image in the presentation, in the end.
CEO got his image in the presentation, in the end.
Version control: A primer

Quick rundown on Coverage

Haven’t looked at many links yet, so this may change.

In general, I can easily see Coverage getting repeated twice, hopefully three times.  The first time would be to hold the game date in the same format as the Date elements will likely be(?): YYYY-MM-DD

The second would hold the city and state of the game, spelled out (for those whose grasp on postal codes are not first-rate or first-hand for those from Canada): “Tuscaloosa, Alabama” or “Lexington, Kentucky”.

These two things can be found at, given year and opposing team, but I’d also like to see field name as the third repetition.  I can see the fields in Wikipedia, but the reference is back to, which doesn’t list the stadiums!  So, yes, I’d like to have “Denny Stadium” or “Dudley Field” listed somewhere, but what would be the proper source.  On another side of this issue, would this be combined with the previous item? “Legion Field ; Birmingham, Alabama”?

Any assistance greatly appreciated.

Quick rundown on Coverage

Curmudgeon-ish Corner Time: Article vs. AD-verticle

Please note: Curmudgeon-ish Corner Time has nothing to do with any Curmudgeon Corners, Curmudgeonly Corners, or general curmudgeon containers.  There’s someone, he’s got some time with a corner, he’s curmudgeon-ish, and he’s gettin’ more curmudgeonly with every trademark issue you bring up.

Okay, so we got this reading for LS566. It’s about DAMs, those Digital Asset Management systems you hear about (five minutes ago, because it’s your class topic).  So, okay, I open up “Rose of D*Mificatin” (what? I want to hear some comment from the author? No. I’m twerkin’ the title).

Uh oh.  Now, first things first.  Adverticles can contain useful information.  And we’ll get into that in another place, but you got to, GOT TO, read them with a fine tooth comb with two questions in mind: What are you trying to get me to believe, and what are you trying to get me to ignore?  Because, as the DAM Foundation article points out, they are trying to get you to believe something that most other sources are not. And they may be trying to get you to ignore, say, the commonly-held definitions of some things.

So, first, suppose I wanted to know what workflow management is (which, as DAM Foundation points out, should definitely be part of a DAM solution). Well, this is an article on that. And this is an honest advertisement with a listicle format. I don’t mind this, which is why I’m just curmudgeon-ish. It’s got points, it actually says at the top what a WMS actually does, the name of the product is at the top and bottom, no one’s trying to pull the wool on you.

But this D*Mificatin’ things just got red flags everywhere. It’s trying to make you feel smart while making you only “business smart”. You know, the smart level of your boss who kept handing you articles to read and highlight the three sentences HE needed to read once he came back from golfin’ with his dad. What are those red flags?

  • It never says it’s written by someone who actually makes the solution until you figure out the “use cases”. In fact, you never find out who the author or company is until you read that little text AFTER THE END OF THE ARTICLE. News flash: Real people usually tell you what they’re doing fairly quickly.
  • It introduces a BS term to tie it to something that “business people” know. Are you wondering why I never write that D word out loud? Do a search for it. NO, you fool, in the private browsing; you don’t want Google knowing you touched this word (man, it’s worse than clicking on any link in The Worst Things for Sale. I still get ads for funny plastic banana slicers). Gee, did you see that word anywhere BUT after “The Rise of”? Gee, is it because it only exists because it rhymes with GAMIFICATION? Think about it, what evidence does the article give that the two have anything in common? Two word clouds with no matching words? A definition that literally says “it’s just like that, but for DAMs” and then ignores any possible link? The only purpose of the word is to get you to feel like you know something new. You don’t; you know something fake.
  • It uses “business verbage” that, essentially, leverages business processes to HALT ANY ACTUAL BUSINESS. Hokey smokes, this thing uses “leverages” twice in the first sentence. And notice that all it does is “adapt quickly to change” and “support positive business growth”. Isn’t that pretty much every mission statement you’ve seen that yells out “I was written by someone who has no idea what their employees do”?
  • The Technology Adoption Lifecycle. Oh, sweet Lord, that effing diagram. Here’s another newsflash: Yes, it’s real. But, like “being cool,” if someone has to tell you about it, you’re not it. You’re not an “innovator” if you buy something no one wants after seeing this curve. Good products never needed this curve to look good. No, you’re on the shorter curve: 2.5% Suckers, 2.5% BIG SUCKERS. And the suckers paid for you to see the curve. Heck, even Steve Jobs fell for the Segway.
  • The diagrams have a generic component replaced by a very specific thing. Look at Figures 5 and 6. That orange diamond. Yeah. You know what the first thing is. What’s the second? Time for private browsing again. Oh, it’s made by the company? I’m shocked. They want you to think that THIS is the future of DAM. Which should raise the question: Is it a DAM? Does it have all of the things that DAM Foundation thinks is important? Or was that the “past”? Or is the future “redefining DAM”?
  • It pits “IT needs” vs. “business person needs”? Because, oh boy, sooner or later, some smart guy in your organization is going to start asking “why doesn’t it do this?” and “why are we paying money for crap that doesn’t even blah blah blah”? And you need to say, “earlier systems had UIs focused on IT needs, limiting its users. This focuses on business person needs.” Because you have the money, you make the decisions. Don’t let Johnny IT boss you around. You never understood this version control junk.

*sips some cold, black coffee* Yeah. Sad thing is, this thing actually has some nice workflow management examples. But too bad, that according to DAM Foundation, a WMS does not a DAM make. So, what do you, Mister or Ms. Library Person, do to protect yourself from business people drunk on adverticles when you want to build a business process system?

Know what you want. Know your requirements. Know what your requirements mean. I’ve known a FEW libraries who are like, “Oh, we have embedded librarians,” and you look, and they seem to have shoehorned SOMETHING into that term, but not what most people recognize. We’re all guilty of shifting definitions to meet our goals, especially when ACRL Survey time comes. So own your definitions. Don’t let people make you feel dumb or nerdy or unfashionable for having them. If they were that great, they wouldn’t be asking YOU for money and work.  Elsevier needs to get off their high horse, I’m tellin’ ya *mike cuts off*

This has been Curmudgeon-ish Corner Time.  Tune in next time, after someone gives this guy a library job when he writes this kind of stuff.  Yeah, keep waiting.

Curmudgeon-ish Corner Time: Article vs. AD-verticle

Mind blown on linked data

I can do a shorter post!  Watch me.

Reading Best Practices for Publishing Linked Data, and I am struck by the fact that Linked Data is structured using one or more vocabularies, which have structure (labels, definition, versions, comments), multilingual support, persistent URIs, wait a second…

Vocabularies are linked data.

Linked data’s structure is other linked data.

It’s turtles all the way down.

Mind blown on linked data

BIBFRAME benefits: RDF vs SQL databases

A nice quick post on Allison Jai O’Dell’s article, On BIBFRAME Interfaces. It sounds like a lot of the confusion on BIBFRAME and RDF benefits comes from not quite getting what databases were doing before.

LS569 is now going through the paces on SQL and database design, and, on occasion, you hear, “Why do librarians have to learn this?”  Little do they know that, in LS566, we’re looking at, “So, what’ll happen after SQL?”  RDF databases don’t use SQL to define their data structures; the analogous technology is SPARQL. So, what are some differences in how our new semantic web databases hold data?

  • SQL as a “set questionnaire” vs. RDF’s “open interview”. SQL databases have a set number of attributes for each of their items.  For example, if I have a DB that holds customers, then I know their first and last name, address, and balance.  I have to then say, for example, that last name is required, that it can’t be more than 50 characters long, and so on.  Every time I make a new customer, the DB sets aside one block of space, always the same size, to hold the data.  It is not easy to change a database once it’s set up.  If a person’s last name is too long, or they don’t have a first name when I require one, or they want two addresses (PO Box!), I’m in trouble.
    RDF doesn’t set aside a block of space right at the beginning.  It goes one statement at a time.  When it gets a last name, it makes space and stores it.  Some databases don’t even edit; if the name changes, they add it as new and mark the old one as old.  If we want to constrain the DB in some way, we have the user interface check for it.  And new types of information are always easily addable.
  • Interoperability.  SQL databases often must speak to each other, but they’re not very good at it.  Even within a company, it’s not uncommon to have two databases, created for different purposes, suddenly have to communicate with each other for a project.  And always, always there will be a “What do you mean you store that as a number?  And you store dashes with your SSNs?” type discussion, and there will be (imperfect) translations, and programs break for a bit, and oh goodness…
    RDF, especially with linked data, does much better with this, because a linked data provides, not only a stable piece of data, but a shared, controlled vocabulary.  If you design your RDF data with these shared vocabularies in mind, then your system understands any other system that shares the lingo.  It’s more like, “yes, I know what people are, and addresses.  You do too?  Okay, we’re good.  Oh, and you know what crochet patterns are?  Wow, okay, well, I’ll pass on any queries for that in your direction.”
  • Fluid user interfaces.  Allison’s right; Ravelry‘s a hoot.  But take a look at their browsing, detail screens, and especially, the advanced search.  It’s incredibly modular.  It’s very easy to add new fields for filters, it quickly adapts to categorical (types of yarn) vs. plain text (designer name) vs. numbers (difficulty level), and it fits a lot of differing types of information into one screen (although it are moving from mobile-friendly design to apps).  In fact, yes, Ravelry has an API.  There may be a SQL DB under all of this, but this is the sort of thing at which RDF excels.  In fact, if Ravelry suddenly wanted to link to another site’s data (which they kind of do, since they allow PayPal), they can, and the user interface will adapt to allow browsing the new information with very little coder input (maybe a “put it here”).

So, there you have it.  What are we doing with Semantic Web?  Adding another assignment to LS569…

BIBFRAME benefits: RDF vs SQL databases