Categories
Intelligent Content

Key Verbs: Actions in Taxonomies

When authors tell stories, verbs provide the action. Verbs move audiences. We want to know “what happened next?” But verbs are hard to categorize in ways computers understand and can act on. Despite that challenge, verbs are important enough that we must work harder to capture their intent, so we can align content with the needs of audiences. I will propose two approaches to overcome these challenges: task-focused and situational taxonomies. These approaches involve identifying the “key verbs” in our content.

Nouns and Verbs in Writing

I recently re-read a classic book on writing by Sir Ernest Gowers entitled The Complete Plain Words. Published immediately after the Second World War, the book was one of the first to advocate the use of plain language.

Gowers attacks obtuse, abstract writing. He quotes with approval a now forgotten essayist G.M. Young:

“Excessive reliance on the noun at the expense of the verb will in the end detach the mind of the writer from the realities of here and now, from when and how, and in what mood this thing was done and insensibly induce a habit of abstraction, generalization and vagueness.”

If we look past the delicious irony — a critique of abstraction that is abstract — we learn that writing that emphasizes verbs is vivid.

Gowers refers to this snippet as an example of abstract writing:

  • “Communities where anonymity in personal relationships prevails.”

Instead, he says the wording should be:

  • “Communities where people do not know one another.”

Without doubt the second example is easier to read, and feels more relevant to us as individuals. But the meaning of the two sentences, while broadly similar, is subtly different. We can see this by diagramming the key components. The strengthening of the verb in the second example has the effect of making the subject and object more vague.

role of verb in sentence

It is easy to see the themes in the first example, which are explicitly called out. The first diagram highlights themes of anonymity and personal relationships in a way the second diagram does not. The different levels of detail in the wording will draw attention to different dimensions.

With a more familiar style of writing, the subject is often personalized or implied. The subject is about you, or people like you. This may be one reason why lawyers and government officials like to use abstract words. They aren’t telling a specific story; they are trying to make a point about a more general concept.

Abstract vs Familiar Styles

I will make a simple argument. Abstract writing focuses on nouns, which are easier for computers to understand. Conversely, content written in a familiar style is more difficult for computers to understand and act on. Obviously, people — and not computers — are the audience for our content. I am not advocating an abstract style of writing. But we should understand and manage the challenges that familiar styles of writing pose for computers. Computers do matter. Until natural language processing by computers truly matches human abilities, humans are going to need to help computers understand what we mean. Because it’s hard for computers to understand discussions about actions, it is even more important that we have metadata that describes those actions.

The table below summarizes the orientations of each style. These sweeping characterizations won’t be true in all cases. Nonetheless, these tendencies are prevalent, and longstanding.

Abstract Style Familiar Style
Emphasis
  • Nouns
  • General concepts
  • Reader is outside of the article context
  • Verbs
  • Specific advice
  • Reader is within the article context
Major uses
  • Represents a class of concepts or events
  • Good for navigation
  • Shows instance of a concept or event
  • Good for reading
Benefits
  • Promotes analytic tracking
  • Promotes automated content recommendations
  • Promotes content engagement
  • Promotes social referrals
Limitations
  • Can trigger weak writing
  • Can trigger weak metadata

These tendencies are not destiny. Steven Pinker, the MIT cognitive scientist turned prose guru, can write about abstract topics in an accessible manner — he makes an effort to do so. Likewise, it is possible to develop good metadata for narrative content. It requires the ability to sense what is missing and implied.

Challenges of a Taxonomy of Verbs

Why is metadata difficult for narrative content? Why is so much metadata tilted toward abstract content? There are three main issues:

  • Indexing relies on basic vocabulary matching
  • Taxonomies are noun-centric
  • Verbs are difficult to specify

Indexing and Vocabulary Matching

Computers rely on indexes to identify content. Metadata is a type of index that identifies and describes the content. Metadata indexes may be based the manual tagging of content (application of metadata) with descriptive terms, or be based on auto-indexing and auto-categorization.

Computers can easily identify and index nouns, often referred to as entities. Named entity recognition can identify proper nouns such as personal names. It is also comparatively easy to identify common nouns in a text when a list of nouns of interest has been identified ahead of time. This is done either through string indexing (matching the character string to the index term) or assigned indexing (matching a character string to a concept term that has been identified as equivalent.)

The manual tagging of entities is also straightforward. A person will identify the major nouns used in a text, and select the appropriate index term that corresponds to the noun. When they decide what things are most important in the article (often the things mentioned most frequently), they find tags that describe those things.

When the text has entities that are proper or common nouns, it isn’t too hard to identify which ones are important and should be indexed. Abstract content is loaded with such nouns, and computers (and people) have an easy time identifying key words that describe the content. But as we will see, when the meaning of a text is based on the heavy use of pronouns and descriptive verbs, the task of matching terms to an index vocabulary becomes more difficult. Narrative content, where verbs are especially important to the meaning, is challenging to index. Nouns are easier to decipher than verbs.

Taxonomies are Noun-centric

When we offer a one-word description, we tend to label stuff using nouns. The headings in an encyclopedia are nouns. Taxonomies similarly rely on nouns to identify what an article is about. It’s our default way of thinking about descriptions.

Because we focus on the nouns, we can easily overlook the meaning carried by the verbs when tagging our content. But verbs can carry great meaning. Consider an article entitled “How to feel more energetic.” There are no nouns in the title to match up with taxonomy terms. Depending on the actual content of the article, it might relate to exercise, or diet, or mental attitude, but those topics are secondary in purpose to the theme of the article, which is about feeling better. A taxonomy may have granular detail, and include a thesaurus of equivalent and related terms, but the most critical issue is that the explicit wording of the article can be translated into the vocabulary used in the taxonomy.

Verbs are Difficult to Specify

Verbs also can be included in descriptive vocabularies for content, but they are more challenging to use. Verbs are sometimes looser in meaning than nouns. Sometimes they are figurative.

graph of verb definition
Verbs such as to make can have many different meanings

A verb may have many meanings. These meanings are sometimes fuzzy. Actions and sentiments can be described by multiple verbs and verbal phrases. Consider the most overworked and meaningless verb used on the web today: to like. If Ralph “likes” this, what does that really mean? Compared to what else? The English language has a range of nuanced verbs (love, being fond of, being interested in, being obsessed with, etc.) to express positive sentiment, though it is hard to demarcate their exact equivalences and differences.

Many common verbs (such as work, make or do) have a multitude of meanings. When the meaning of a verbs is nebulous, it is takes more work to identify the preferred synonym used in a taxonomy. Consider this example from a text-tagging tool. The person reading the text needs to make the mental leap that the verb “moving” refers to “money transfer.” The task is not simply to match a word, but to represent a concept for an activity. We often use imprecise verb like move instead of more precise verb like transfer money. Such verbal informality makes tagging more difficult.

Tagging a verb with a taxonomy term.  Screenshot via Brat.
Tagging a verb with a taxonomy term. Screenshot via Brat.

With the semantic web, predicates play the role of verbs defining the relationship between subjects and objects. The predicates can have many variants to express related concepts. If we say, “Jane Blogs was formerly married to Joe Blogs,” we don’t know what other verbal phrase would be equivalent. Did Jane Blogs divorce Joe Blogs? Did Joe Blogs die? Another piece of information may be needed to infer the full meaning. Verbal phrases can carry a degree of ambiguity, and this makes using a standard vocabulary for verbs harder to do.

Samuel Goto, a software engineer at Google, has said: “Verbs … they are kind of weird.”

Computers can’t understand verbs easily. Verb concepts are challenging for humans to describe with standardized vocabulary. Tagging verbs requires thought.

Why Verb Metadata Matters

If verbs are a pain to tag, why bother? So we can satisfy both the needs of our audiences and the needs of the computers that must be able to offer our audiences precisely what they want. As an organization, we need to make sure all this is happening effectively. We need to harmonize three buckets of needs: audience, IT, and brand.

Audience needs: Most audiences expect content written in familiar style, and want content with strong, active verbs. Those verbs often carry a big share of the meaning of what you are communicating. Audiences also want precise content, rather than hoping to stumble on something they like by accident. This requires good metadata.

IT needs: Computers have trouble understanding the meaning of verbs. Computers need a good taxonomy to support navigation through the content, and deliver good recommendations.

Brand needs: Brands need to be able to manage and analyze content according to the activities discussed in the content, not just the static nouns mentioned in it. If they don’t have a plan in place to identify key verbs in their content, and tag their meaning, they run the risk of having a hollow taxonomy that doesn’t deliver the results needed.

A solution to these competing needs is to have our metadata represent the actions mentioned in the content. I’m calling this approach finding your key verbs.[1]

Approaches to a Metadata of Actions

Two approaches are available to represent verb concepts. The first is to make verbs part of your taxonomy. The second is to translate verbs in your content into nouns in your taxonomy.

Task-focused Taxonomies

The first approach is to develop a list of verbs that express the actions discussed in your content. Starting with the general topics about which you produce content, you can do an analysis and see what specific activities the content discusses. We’ll call these activities “tasks.”

Think about the main tasks for the people we want to reach. How do they talk about these tasks? People don’t label themselves as a new-home buyer: they are looking for a new home. They may never actually buy, but they are looking. Verbs help us focus on what the story is. There may be sub tasks that our reader would do, and would want to read about. Not only are they looking for a new home, they are evaluating kitchens and getting recommendations on renovations. This task focus is important to help us manage content components, and track their value to audience segments. We can do this using a task-focused taxonomy.

I am aware of two general-purpose taxonomies that incorporate verbs. The tasks these taxonomies address may differ from your needs, but they may provide a starting point for building your own.

The new “actions” vocabulary available in schema.org is the better known of the two. Schema.org has identified around 100 actions “to describe what can be done with resources.” The purpose is to be able not only to find content items according to the action discussed, but to enable actions to be taken with the content. As a simple example, you might find an event, and click a button to confirm your attendance. Behind the scenes, that action will be managed by the vocabulary.

The schema actions are diverse. Some describe high-level activities such as to travel, while others refer to very granular activities, such as to follow somebody on a social network. Some task are real world tasks, and others strictly digital ones. I presume real-world actions are included to support activity-reporting from the Internet of Things (IoT) devices that monitor real-world phenomena such as exercise.

screenshot of schema.org actions terms
Schema.org actions taxonomy (partial)

Framenet, a semantic tagging vocabulary used by linguists, is a another general vocabulary that provides coverage of verbs. If a sentence uses the verb “freeze” (in the sense of “to stop”), it is tagged with the concept of “activity_pause.” It is easiest to see how Framenet verb vocabulary works using an example from David Caswell’s project, Structured Stories. Verbs that encapsulate events form the core of each story element. [2]

screenshot structured stories
Screenshot from the Structured Stories project, which uses Framenet.

Applications of Task Taxonomies

While both these vocabularies describe actions at the sentence or statement level, they can be applied to an entire article or section of content as well.

A task focus offers several benefits. Brands can track and manage content about activities independently of who specifically is featured doing the activity, or where/what the object or outcome of the activity is. So if brands produce content discussing options to travel, they might want to examine the performance of travel as a theme, rather than the variants of who travels or where they travel.

Task taxonomies also enable task-focused navigation, which lets people to start with an activity, then narrow down aspects of it. A sequence might start: What do you want to do? Then ask: Where would you like to do that? The sequence can work in reverse as well: people can discover something of interest (a destination) and then want to explore what to do there (a task).

Situational taxonomies

A second option uses nouns to indicate the notable events or situations discussed. Using nouns as proxies for actions unfortunately doesn’t capture a sense of dynamic movement. But if you can’t support a faceted taxonomy that can mix nouns and verbs, it may be the most practical option. When you have a list of descriptors that express actions discussed in your content, you are more likely to tag these qualities than if your taxonomy is entirely thing-centric. I’ll call a taxonomy that represents occasions using noun phrases a situational taxonomy. The terms in a situational taxonomy describe situations and events that may involve one or more activities.

If you have ever done business process modeling, you are familiar with the idea of describing things as passing through a routine lifecycle. We reify activities by giving them statuses: a project activity is under development, in review, launched, and so on. Many dimensions of our work and life involve routines with stages or statuses. When we produce content about these dimensions, we should tag the situation discussed.

One way to develop a situational taxonomy is by creating a blueprint of a detailed user journey that includes an end-to-end analysis of the various stages that real-world users go through, including the “unhappy path” where they encounter a situation they don’t want. Andrew Hinton has made a compelling case in his book Understanding Context that the situations that people find themselves in drive the needs they have. Many user journey maps don’t name the circumstances, they jump immediately into the actions people might do. Try to avoid doing that. Name each distinct situation: both the ones actively chosen by them as well as those foisted on them. Then map these terms to your content.

Situational taxonomies are suited to content about third parties (news for example) or when emphasizing the outcomes of a process rather than the factors that shape it. Processes that are complex or involve chance (financial gyrations or a health misfortune, for example) are suited to situational taxonomies. A situational taxonomy term describes “what happened?” at a high level. Thinking about events as a process or sequence can help to identify terms to describe the action discussed in the content.

The technical word for making nouns out of verbs is “nominalization.” For example, the verb “decide” becomes the noun “decision.” Not all nominalizations are equal: some are very clunky or empty of meaning. Decision is a better word than determination, for example. Try to keep situational terms from becoming too abstract.

Situational taxonomies are less granular than task-based ones. They provide an umbrella term that can represent several related actions. They can enhance tracking, navigation and recommendations, but not as precisely as task-based terms. Task taxonomies express more, suggesting not only what happens, but also how it happens.

Key Verbs Mark the Purpose of the Content

Identifying key verbs can be challenging work. Not all headlines will contain verbs. But ideally the opening paragraph should reveal verbs that frame the purpose of the article. Content strategists know that too much content is created without a well-defined purpose. Taxonomy terms focused on actions indicate what happens in the content, and suggest why that matters. Headlines, and taxonomy terms that rely entirely on nouns, don’t offer that.

We will look at some text from an animal shelter. I have intentionally removed the headline so we can focus on the content, to find the core concepts discussed. A simple part-of-speech app will allow us to isolate different kinds of words. First we will focus on the verbs in the text, which includes the terms “match”, “spot”, “suit”, “ask”, and “arrange”. The verb focus seems to be “matching.” Matching could be a good candidate term in a task taxonomy.

part of search view of verbs in narrative

Now we’ll look at nouns. In additional to common nouns such as dogs and families, we see some nouns that suggest a process. Specifically, several nouns include the word “adoption.” Adoption would be a candidate term in a situational taxonomy. Note the shift in focus: adoption suggests a broader discussion about the process, whereas matching suggests a more specific goal.

part of search view of nouns in narrative

When you look at content through the lens of verbs, questions arise. What verbs capture what the content is describing? Why is the content here? What is the reader or viewer supposed to do with this information? Could they tell someone else what is said here?

If you are having trouble finding key verbs, that could indicate problems with the content. Your content may not describe an activity. There is plenty of content that is “background content,” where readers are not expected to take any action after reading the content. If your goal for producing the content is simply to offer information for reference purposes, then it is unlikely you will find key verbs, because the content will probably be very noun-centric. The other possibility is that the writing is not organized clearly, and so key actions discussed are not readily seen. Both possibilities suggest a strategy check-up might be useful.

Avoid a Hollow Taxonomy

Even when tagging well-written content, capturing what activity is represented will require some effort. This can’t be automated, and the people doing the tagging need to pay close attention to what is implied in the content. They are identifying concepts, not simply matching words.

Tagging is easier to do when one already has vocabulary to describe the activities mentioned in your content. That requires auditing, discovery and planning. If your taxonomy only addresses things and not actions, it may be hollow. It can have gaps.

Most content is created to deliver an outcome. Metadata shouldn’t only describe the things that are mentioned. It should describe the actions that the content discusses, which will be explicitly or implicitly related to the actions you would like your customers to take. You want to articulate within metadata the intent of the content, and thus be in a position to use the content more effectively as a result. Key verbs let you capture the essence of your content.

By identifying key verbs, brands can use active terminology in their metadata to deliver content that is aligned with the intent of audiences.

diagram of key verb roles
How key verb metadata can support content outcomes

The Future Web of Verbs

Web search is moving “from the noun to the verb,” according to Prabhakar Raghavan, Google’s Vice President of Engineering.

We are at the start of a movement toward a web of verbs, the fusing of content and actions. Taxonomy is moving away from its bookish origins as the practice of describing documents. Its future will increasingly be focused on supporting user actions, not just finding content. But before we can reach that stage, we need to understand the relationship between the content and actions of interest to the user.

Taxonomies need to reflect the intent of the user. We can understand that intent better when we can track content according to the actions it discusses. We can serve that intent better when we can offer options (recommendations or choices) centered on the actions of greatest interest to the user.

The first area that verb taxonomies will be implemented will likely be transactional ones, such as making reservations using Schema actions. But the applications are much broader than these “bottom of the funnel” interventions. Brands should start to think about using action-oriented taxonomy terms through their content offerings. This is an uncharted area, linking our metadata to our desired content outcomes.

— Michael Andrews


  1. Key verbs build on the pre-semantic idea of key words, but are specific to activities, and represent concepts (semantic meaning) instead of literal word strings.  ↩
  2. You can watch a great video of the process on YouTube.  ↩
Categories
Content Sharing

Thinking Beyond Semantic Search

Publishers are quickly adopting semantic markup, yet often get less value from it than they could. They don’t focus on how audiences can directly access and use their semantically-described content. Instead, publishers rely on search engines to boost their engagement with audiences. But there are limits to what content, and how much content, search engines will present to audiences.  Publishers should leverage their investment in semantic markup.  Semantically-described content can increase the precision and flexibility of content delivery.  To realize the full benefits of semantic markup, publishers need APIs and apps that can deliver more content, directly to their audiences, to help individuals explore content that’s intriguing and relevant.

The Value of Schema.org Markup

Semantic search is a buzzy topic now. With the encouragement of Google, SEO consultants promote marking up content with Schema.org so that Google can learn what the content is. A number of SEO consultants suggest that brands can use their markup to land a coveted spot in Google’s knowledge graph, and show up in Google’s answer box. There are good reasons to adopt Schema.org markup.  It may or may not boost traffic to your web pages.  It may or may not boost your brand’s visibility in search.  But it will help audiences get the information they need more quickly.  And every brand needs to be viewed as helpful, and not as creating barriers to access to information customers need.

But much of the story about semantic search is incomplete and potentially misleading. Only a few lucky organizations will manage to get their content in Google’s answer box. Google has multiple reasons to crawl content that is marked up semantically. Besides offering search results, Google is building its own knowledge database it will use for its own applications, now and in the future.  By adding semantic annotation to their content that Google robots then crawl, publishers provide Google a crowd-sourced body of structured knowledge that Google can use for purposes that may be unrelated to search results. Semantic search’s role as a fact-collection mechanism is analogous to Google’s natural-language machine learning it developed through their massive book-scanning program several years ago.

Publishers rely on Google for search visibility, and effectively grant Google permission to crawl their content unless they indicate no-robots. Publishers provide Google with raw material in a format that’s useful to Google, but they can fail to ask how that format is useful to them as publishers. As with most SEO, publishers are being told to focus on what Google wants and needs. Unless one pays close attention to what is happening with developments with Schema.org, one will get the impression that the only reason to create this metadata is to please Google.  Google is so dominant that it seems as if it is entirely Google’s show.  Phil Archer, data activity lead at the W3C, has said: “Google is the killer app of the semantic web.”  Marking up content in Schema.org clearly benefits Google, but it often doesn’t help publishers nearly as much as it could.

Schema.org provides schemas “to markup HTML pages in ways recognized by major search providers, and that can also be used for structured data interoperability (e.g. in JSON).” According to its FAQs, its purpose is “to improve the web by creating a structured data markup schema supported by major search engines.”  Schema.org is first and foremost about serving the needs of search engines, though it does provide the possibility for data interoperability as well.  I want to focus on the issue of data interoperability, especially as it relates to audiences, because it is a widely neglected dimension.

Accessing Linked Data

Semantic search markup (Schema.org), linked data repositories such as GeoNames, and open content such as Wikipedia-sourced datasets of facts (DBpedia) all use a common, non-proprietary data model (RDF).  It is natural to view search engine markup as another step in the growth in the openness of the web, since more content is now described more explicitly.  Openness is a wonderful attribute: if data is not open, that implies it is being wasted, or worse, hoarded.  The goal is to publish your content as machine-intelligible data that is publicly accessible.  Because it’s on the web in a standardized format, anyone can access it, so it seems open.  But the formal guidelines that define the technological openness of open data are based more on standards-compliance by publishers than approachability by content consumers.  They are written from an engineering perspective. There is no notion of an audience in the concept of linked data. The concept presumes that the people who need the data have the technical means to access and use it.  But the reality is that much content that is considered linked data is effectively closed to the majority of people who need it, the audience for whom it was created. To access the data, they must rely on either the publisher, or a third party like Google, to give them a slice of what they seek.  So far, it’s almost entirely Google or Bing who have been making the data audience-accessible.  And they do so selectively.

Let’s look at a description of the Empire State Building in New York.  This linked data might be interesting to combine with other linked data concerning other tall buildings.  Perhaps school children will want to explore different aspects of tall buildings.  But clearly, school children won’t be able to do much with the markup themselves.

json-ld for empire state building
Schema.org description of Empire State Building in JSON-LD, via JSON-LD.org

If one searches Google for information on tall buildings, they will provide an answer that draws on semantic markup.  But while this is a nice feature, it falls short of providing the full range of information that might be of interest, and it does not allow users to explore the information the way they might wish.  One can click on items in the carousel for more details, but the interaction is based on drilling-down to more specific information, or requiring a new search query, rather than providing a contextually dynamic aggregation of information.  For example, if the student wants to find out which architect is responsible for the most tall buildings in the world, Google doesn’t offer a good way to get to that information iteratively.  If the student asks Google “which country has the most tall buildings?” she is simply given a list of search results, which includes a Wikipedia page where the information is readily available.

Relying on Google to interpret the underlying semantic markup means that the user is limited to the specific presentation that Google chooses to offer at a given time.  This dependency on Google’s choices seems far from the ideals promised by the vision of linked open data.

screenshot of google search results
Screenshot of Google search for tallest buildings

Google and Bing have invested considerable effort in making semantic search a reality: communication campaigns to encourage implementation of semantic markup, and technical resources to consume this markup to offer their customers a better search experience.  They crawl and index every word on every page, and perform an impressive range of transformations of that information to understand and use it.  But the process that the search engines use to extract meaning from content is not something that ordinary content consumers can do, and in many ways is more complicated that it needs to be.  One gets a sense of how developer-driven that semantic search markup is by looking at the fluctuating formats used by Schema.org.  There are three different markup languages (microdata, RDFa, and JSON-LD) with significantly different ways of characterizing the data.  Google’s robots are sophisticated enough to be able to interpret any of the types of markup.  But people not working for a search engine firm need to rely on something like Apache Any23, a Java library, to extract semantic content marked up in different formats.

Screenshot of Apache Any23
Screenshot of Apache Any23

Linked Data is Content that needs a User Interface

How does an ordinary person link to content described with Schema.org markup? Tim Berners-Lee famously described linked data as “browseable data.” How can we browse all this great stuff that’s out there, that’s been finally annotated so that we get the exact bits we want?  Audiences should have many avenues to retrieving content so that they can use it in the context where they need it. They need a user interface to the linked data.  We need to build this missing user interface.  For this to happen, there need to be helpful APIs, and easy-to-use consumer applications.

APIs

The goal of APIs is to find other people to promote the use of your content.  Ideally, they will use your content in ways you might not even have considered, and therefore be adding value to the content by expanding its range of potential use.

APIs play a growing role in the distribution of content.  But they often aren’t truly open in the sense they offer a wide range of options to data consumers.  APIs thus far seem to play a limited role in enabling the use of content annotated with  schema.org markup.

Getting data from an API can be a chore, even for quantitatively sophisticated people who are used to thinking about variables.  AJ Hirst, an open data advocate who teaches at the Open University, says: “For me, a stereotypical data user might be someone who typically wants to be able to quickly and easily get just the data they want from the API into a data representation that is native to the environment they are working in, and that they are familiar with working with.”

API frictions are numerous: people need to figure out what data is available, what it means, and how they can use it.  Hirst advocates more user-friendly discovery resources. “If there isn’t a discovery tool they can use from the tool they’re using or environment they’re working in, then finding data from service X turns into another chore that takes them out of their analysis context.”  His view: “APIs for users – not programmers. That’s what I want from an API.”

The other challenge is that query-possibilities for semantic content go beyond the basic functions commonly used in APIs.

Jeremiah Lee, an API designer at Fitbit, has thought about how to encourage API providers and users to think more broadly about what content is available, and how it might be used.  He notes: “REST is a great starting point for basic CRUD operations, but it doesn’t adequately explain how to work with collections, relational data, operations that don’t map to basic HTTP verbs, or data extracted from basic resources (such as stats). Hypermedia proponents argue that linked resources best enable discoverability, just as one might browse several linked articles on Wikipedia to learn about a subject. While doing so may help explain resource relationships after enough clicking, it’s not the best way to communicate concepts.”

For Linked Data, a new API standard is under development called hydra that aims to address some of the technical limitations of standard APIs that Lee mentions.  But the human challenges remain, and the richer the functionality offered by an API, the more important it is that the API be self-describing.

Fitbit’s API, while not a semantic web application, does illustrate some novel properties that could be used for semantic web APIs, including a more visually rich presentation with more detailed descriptions and suggestions available via tooltips.  These aid the API user, who may have various goals and levels of knowledge relating to the content.

Screenshot of Fitbit API
Screenshot of Fitbit API

Consumer apps

The tools available to ordinary content users to add semantic descriptions have become more plentiful and easier to use.  Ordinary web writers can use Google’s data highlighter to indicate what content elements are about.  Several popular CMS platforms have plug-ins that allow content creators to fill-in forms to describe the content on the page.  These kinds of tools hide the markup from the user, and have been helpful in spurring adoption of semantic markup.

While the creation of semantic content has become popularized, there has not been equivalent progress in developing user-friendly tools that allow audiences to retrieve and explore semantic content. Paige Morgan, an historian who is developing a semantic data set of economic information, notes: “Unfortunately, structuring your data and getting it into a triplestore is only part of the challenge. To query it (which is really the point of working with RDF, and which you need to do in order to make sure that your data structure works), you need to know SPARQL — but SPARQL will return a page of URIs (uniform resource identifiers — which are often in the form of HTML addresses). To get data out of your triplestore in a more user-friendly and readable format, you need to write a script in something like Python or Ruby.  And that still isn’t any sort of graphical user interface for users who aren’t especially tech-savvy.”

We lack consumer-oriented applications that allow people to access and recombine linked data.  There is no user interface for individuals to link themselves to the linked data.  The missing UI reflects a legacy of seeing linked data as being entirely about making content machine-readable.  According to legacy thinking, if people needed to directly interact with the data, they could download it to a spreadsheet.  The term “data” appeals to developers who are comfortable thinking about content structured as databases, but it doesn’t suggest application to things that are mentioned in narrative content.  Most content described by Schema.org is textual content, not numbers, which is what most non-IT people consider as data.  And text exists to be read by people.  But the jargon we are stuck with to discuss semantic content means we emphasize the machine/data side of the equation, rather than the audience/content side of it.

Linked data in reality are linked facts, facts that people can find useful in a variety of situations.  Google Now is ready to use your linked data and tell your customers when they should leave the house.  Google has identified the contextual value to consumers of linked data.  Perhaps your brand should also use linked data in conversations with your customers.  To do this, you need to create consumer facing apps that leverage linked data to empower your customers.

Wolfram Alpha is a well-known consumer app to explore data on general topics that has been collected from various sources.  They characterize their mission, quite appealingly, as “democratizing data.” The app is user friendly, offering query suggestions to help users understand what kinds of information can be retrieved, and refine their queries.  Their solution is not open, however.  According to Wolfram’s Luc Barthelet, “Wolfram|Alpha is not searching the Semantic Web per se. It takes search queries and maps them to an exact semantic understanding of the query, which is then processed against its curated knowledge base.” While more versatile than Google search in the range and detail of information retrieved, it is still a gatekeeper, where individuals are dependent on the information collection decisions of a single company.  Wolfram lacks an open-standards, linked-data foundation, though it does suggest how a consumer-focused application might use of semantic data.

The task of developing an app is more manageable when the app is focused on a specific domain.  The New York Times and other news organizations have been working with linked data for several years to enhance the flexibility of the information they offer.  In 2010 the Times created an “alumni in the news” app that let people track mentions of people according to what university they attended, where the educational information was sourced from DBpedia.

New York Times Linked Data app for alumni in the news.  It relied in part on linked data from Freebase, a Google product that Google is retiring.
New York Times Linked Data app for alumni in the news. It relied in part on linked data from Freebase, a Google product that Google is retiring that will be superseded by Wikidata.

A recent example of a consumer app that is using linked data is a sports-oriented social network called YourSports.  The core metadata of the app is built in JSON-LD, and the app creator is even proposing extensions to Schema.org to describe sports relationships.  This kind of app hides the details of the metadata from the users, and enables them to explore data dimensions as suits their interests.  I don’t have direct experience of this app, but it appears to aggregate and integrate sports-related factual content from different sources.  In doing so, it enhances value for users and content producers.

Screenshot of Yoursports
Screenshot of Yoursports

Opening up content, realizing content value

If your organization is investing in semantic search markup, you should be asking: How else can we leverage this?  Are you using the markup to expose your content in your APIs so other publishers can utilize the content?  Are you considering how to empower potential readers of your content to explore what you have available?  Consumer brands have an opportunity to offer linked data to potential customers through an app that could result in lead generation.  For example, a travel brand could use linked data relating to destinations to encourage trip planning, and eventual booking of transportation, accommodation, and events.  Or an event producer might seed some of its own content to global partners by creating an API experience that leverages the semantic descriptions.

The pace of adoption for aspects of semantic web has been remarkable. But it is easy to overlook what is missing.  A position paper for Schema.org says “Schema.org is designed for extremely mainstream, mass­-market adoption.”  But to consider the mass-market only as publishers acting in their role as customers of search engines is too limiting.  The real mainstream, mass-market is the audience that is consuming the content. These people may not even have used a search engine to reach your content.

Audiences need ways to explore semantically-defined factual content as they please.  It is nice that one can find bits of content through Google, but it would be better if one didn’t have to rely solely only on Google to explore such content.  Yes, Google search is often effective, but search results aren’t really browseable.  Search isn’t designed for browsing: it’s designed to locate specific, known items of information.  Semantic search provides a solution to the issue of too much information: it narrows the pool of results.  Google in particular is geared to offering instant answers, rather than sustaining an engaging content experience.

Linked data is larger than semantic search.  Linked data is designed to discover connections, to see themes worth exploring. Linked data allows brands to juxtapose different kinds of information together that might share a common location or timing, for example. Individuals first need to understand what questions they might be interested in before they are ready for answers to those questions. They start with goals that are hard to define in a search query.  Linked data provides a mechanism to help people explore content that relates to these goals.

While Google knows a lot about many things relating to a person, and people in general, it doesn’t specialize in any one area.  The best brands understand how their customers think about their products and services, and have unique insights into the motivations of people with respect to a specific facet of their lives.  Brands that enable people to interact with linked data, and allow them to make connections and explore possibilities, can provide prospective customers something they can’t get from Google.

— Michael Andrews