Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

Why Tumblr Was a Massive Steal for Yahoo by Adam Rifkin.

Adam makes two critical points for topic maps marketing:

First, Tumblr is an interest not a social graph. That is people are looking for context of interest to them.

Second, as Adam writes:

Writers have time but no money. Certain groups are going to be overrepresented: Students, stay-at-home moms, the underemployed, retirees. Epinions, which paid for product reviews, especially ran into issues with writers whose relationship to reviewed products lay more in the realm of fantasy than reality. Writers are also going to have the time and emotional commitment to give your site a lot of feedback about their needs and desires … many of which will be counter to the best interests of the business.

Readers have money but no time. They don’t want to spend hours combing the Internet for photos of vintage jewelry. They want to see a picture of a watch they like, and buy it now. If readers don’t find your content valuable, they’re not going to send you a long email about what they don’t like. They’ll just silently hit the back button and get gone.

Test:

In marketing a topic map, which of the following are more important?:

1. Writers can contribute their input to a public topic map interface?
2. Readers can purchase access to high quality content?

You have until your VC funding runs out to decide.

Atlassian’s Causium Sales Model Reaches $2.5 Million Charity Donations by Kit Eaton.

From the post:

Back in May 2010 Atlassian, a large innovative software company, revealed that its alternative business model causium had allowed it to donate $500,000 to international literacy improvement charity Room to Read. Now the firm says it has surpassed $2.5 million in donations, and is holding a special event with the charity on May 14th to celebrate.

Causium is an alternative to the freemium business model that many companies–from the Wall Street Journal to Babbel–follow. Under freemium thinking, Atlassian would give away some of its enterprise-grade code for free in order to attract business for its paid services. But instead, the company charges a nominal $10 fee, which it then donates to charity. The fee works in two ways–as a boost to charitable causes, and also to demonstrate to the software’s end-users that the code itself has value.

Atlassian’s President Jay Simons spoke to Fast Company, explaining that the plan has worked better than they expected: “We didn’t appreciate at the time that we were effectively building this annuity stream. Customers that buy the 10-user license will buy it again the following year.” The first year of the plan resulted in some $300,000 in charity donations, and the growth of the company’s reputation since means they donated the same amount in the first quarter of 2013. The donations are important to Room to Read, Simons says, because “they have a reliable funding source” on a regular basis.

Important to note that Atlassian had the market presence to make a causium sales model work.

On that score, see:

Why Atlassian is to Software as Apple is to Design by Mark Fidelman.

and, of course:

Atlassian.

Important lessons if you hope to make your software or service a success.

How to Go Viral, Every Time by Jess Bachman.

From the post:

Everyone wants their content to go viral. It’s the holy grail of marketing. It can turn companies and product into the talk of the town, even if they sell toiletries. The ROI on content with more than a million views is almost unmeasurable. So how do you make sure your content will go viral?

The secret is simple. Be incredibly lucky.

Luck is the third piece of the virality triumvirate and obviously the hardest to bank on. In fact, you cannot achieve true virality without it. With great content and powerful tactics you can certainly get millions of views on a consistent basis, but if lady luck doesn’t give her blessing, you will end up with a good – but not great – ROI.

What do you think would make good viral material for a topic map video?

And of course:

Anyone with skills at producing videos interested in a topic map video?

HowTo: Develop Your First Google Glass App [Glassware] by Tarandeep Singh.

From the post:

Google has raised curtains off it’s Glass revealing detailed Tech Specs. Along with the specs came the much awaited Mirror API – The API for Glass apps.

So you had that killer app idea for Google Glass? Now its time for you to put those ideas into code!

The race is on to produce the first topic map based Google Glass App!

A response to a request can be a machine generated guess or a human curated answer.

Which one do you think users would prefer?

If you haven’t seen Glass, go to: http://www.google.com/glass/start/

If lame search results are annoying on your desktop, pad or cellphone, imagine not being able to escape them.

Of for a positive spin, would you want a service provider with better results?

Bad data “in your face” may be the selling point we need.

Dylan Jones writes in Data Quality: One Habit at a Time:

I started learning about data quality management back in 1992. Back then there were no conferences, limited publications and if you received an email via the internet the excitement lasted for hours.

Fast forward to today. We are practically swamped with data quality knowledge outlets. Sites like the Data Roundtable, OCDQ Blog and scores of other data quality bloggers provide practical ideas and techniques on an almost hourly basis.

We never lack for ideas and methods for implementing data quality management, and of course this is hugely beneficial for professionals looking to mature data quality in their organisation.

However, with all this knowledge comes a warning. Data quality management can only succeed when behaviours are changed, but to change a person’s behaviour requires the formation of new habits. This is where many projects will ultimately fail.

Have you ever started the New Year with a promise to change your ways and introduce new habits? Perhaps the guilt of festive excesses drove you to join a gym or undertake some other new health regime. How was that health drive looking in March? How about September?

The problem of habit formation is exacerbated when we attempt to change multiple habits. Perhaps we want to combine a regular running regime with learning new skills. The result is often failure.

Does your topic maps sales pitch require too much change? (I know mine does.)

Or do you focus on the one issue/problem that your client needs solving?

Sure, topic maps enable robust integration of diverse data stores but it that’s not your clients issue, why bring it up?

Can we sell more by promising less?

Most topic map software, either explicitly or implicitly, is targeted at developers.

I ran across a graphic today that highlights what I consider to be a flaw in that strategy.

The original graphic concerns the number of students enrolled in computer science:

I first saw that in a tweet by Matt Asay.

I need to practice (read learn) Gimp skills so my first attempt to re-purpose the graphic was:

But that leaves my main point implied, so after some fiddling, I got:

Even without a marketing degree, I can pick the better marketing target.

What about you?

BTW, the experience with Hadoop supports my side, not the targeting for developers argument.

Yes, a lot of Hadoop tools are difficult to use, if not black arts.

However, Hadoop marketing has more hand waving and arm flapping than you will see among Democrats on entitlement reform and Republicans on tax reform, combined.

The Hadoop ecosystem (which I like a lot by the way) is billed to consumers as curing everything but AIDS and that is just a matter of application.

Consumer demand, from people who aren’t going to run Hadoop clusters, write pig scripts, etc. is driving developers to build better tools and to learn the harder ones.

Suggestions on how to build consumer oriented marketing of topic maps will be greatly appreciated!

You may already be aware of threats and legal proceedings by Edwin Mellen Press against criticism of itself and its publications.

For one recent update, see: Posts Removed Because We’ve Received Letters From Edwin Mellen Press’ Attorney by Kent Anderson.

For further background, see: When Sellers and Buyers Disagree — Edwin Mellen Press vs. a Critical Librarian by Rick Anderson.

The thought occurs to me that over the years there must be a treasure trove of letters and other communications from Edwin Mellen Press, not to mention litigation files, depositions, etc.

But any story about Edwin Mellen Press will be written with access to only part of that historical information.

What if McMaster University were to publicize the “…demands and considerable pressure from the Edwin Mellen Press….?” And those demands could be mapped to other demands against others?

The demands by Edwin Mellen Press have been made against librarians. The very people who excel at the collection and creation of archives.

Is it time for the library community to pool its knowledge about Edwin Mellen Press?

My time resources are limited but I would be willing to contribute as I am able to such an effort.

You?

On the eight day of creation [language and time units are for the convenience of the reader. The celestial court exists outside of their strictures].

I started this post off as an April Fools Day gag but the keyboard ran away from me.

See what you think.

L = Lord

O = Other member(s) of the celestial court

L: The Tower of Babel is another example of bad PR from my own followers.

O: How so? Didn’t you confuse their languages to prevent an assault on Heaven?

L: Look around you. It is likely I would be fearful of someone piling up bricks to assault Heaven?

O: Well, now that you mention it, no, it doesn’t seem likely. (In an uncertain tone of voice.)

L: Would it help if I explained why humans invented the story of the Tower of Babel?

O: Nodding quickly.

L: Arrogance.

O: Arrogance?

L: Think about it. There are two types of people. One type thinks they know what and how everyone else should be thinking. The other type knows who should be telling others what and how to think.

The Tower of Babel story blames me for the competition to force others to a single way of thinking.

What’s ironic is their arrogance multiplies the number of languages and approaches to languages. Every generation denigrates what went before, for a new bumper crop of shiny “truths.”

Need an example?

Take their “when in the beginning there was FORTRAN….”

Now look at any listing of major programming languages, never mind the smaller ones.

No Tower of Babel story there.

O: What about the Tower of Babel as an explanation for different languages?

L: Glad you asked.

I’ll give you one guess who thinks they are entitled to an explanation for everything.

More listening to others and less whining about not being in charge would be a start towards less confusion of languages.

The Telenor post reminded me about my arguments about topic maps saving users time by not (re)searching for information already found.

In Telenor’s case, there was someone, customers in fact, who wanted faster and more accurate information.

Is there a business case for avoiding (re)searching for information already found?

Say where research is being billed to a client by the hour?

The more attorneys, CPAs, paralegals, etc. that find the same information = more billable hours.

Where a topic map = fewer billable hours.

And where billable hours aren’t an issue, what do users do with the time they used to spend on the appearance of working by searching?

I am reminded of a then department manager who described themselves as “…doing market research…” by reading the latest issue of Computer Shopper. Nearly twenty (20) years ago now but even then there were more effective means of such research.

On the other hand, there may be cases where use of topic maps by one side may force others to improve their game.

Intelligence gathering and processing for example.

Topic maps need not disrupt current layers of contracting, feathered nests and revolving doors, to say nothing of the turf guardians.

But topic maps could envelope such systems, in place, to provide access to integrated inter-agency intelligence, long before agreement is reached (if ever) on what intelligence to share.

Thinking of ways that topic maps are the same or different from other information technologies.

Your Data: I think all information technologies would claim to handle your data. Some focus more on structured data that others but in general, all handle “your data.”

Your Model: This is where topic maps and key/value stores depart from the Semantic Web.

You don’t get “your model” with the Semantic Web, you get a prefab logical model.

Contrast that with topic map where you can have FOL (first order logic), SOL (second order logic) or any other logic or non-logic you choose to have. It’s your model and it operates as you think it should. Could even be: “go ask Steve” for some operations.

The Semantic Web types will protest not using their model means your data won’t work with their software. Which is one of their main reasons for touting their model. It works with their software.

Personally I prefer models that fit my use cases. As opposed to models whose first requirement is to work on a particular class of software.

Guess it depends on whether you want to further the well being of Semantic Web software developers or your own.

Your Vocabulary: Another point where topic maps and key/value stores depart from the Semantic Web.

The vocabulary you choose for your model is your own.

Which is very likely to be more familiar and you can apply it more accurately.

How do topic maps differ from key/value stores?

Two things come to mind. First, topic maps have inherent machinery for the representation of relationships between subjects.

Not that you could not do that with a key/value store but in some sense a key/value store is more primitive than a topic map. You would have to build up such structures for yourself.

Second, “as is,” key/value stores (at least the ones I have seen, which isn’t all of them), don’t have a well developed notion of subject identity.

That is keys and values are both treated as primitives. If your key and my key aren’t the same, then they must be different. Or if they are the same, then they must be the same thing. Same for values.

That may not be a disadvantage in some cases where information aggregation or merging isn’t a requirement. But it is becoming harder and harder to think of use cases where aggregation/merging isn’t ever going to be an issue.

I need to cover issues like the differences between topic maps and key/value stores more fully.

Would you be interested in longer pieces that could eventually form a book on topic maps?

Perhaps even by subscription?