In my last post on digital context, we took a trip back to logic class, looking at how we could begin to describe our world using “sentences” based on first order logic. This essential “predicate semantics” is the foundation of all mathematics, and hence, computing. In fact, it’s the basis for our most key data storage mechanisms (think SQL). With so much of structured information already encoded in this predicate representation, this gives us an excellent foundation for more semantically-driven contextual computing.

And that’s what today’s post is all about. (If you’d like to catch up on my unfolding story on context first, you can begin here: one, two, three.)

Let’s Begin at the Beginning: What is Context, Anyway?

According to my Webster’s, the word “context” comes from the Latin ”contextus,” which means a joining or weaving together. There are a couple of different types of context:

  1. There’s context as represented through language, or “the parts of a sentence, paragraph, or discourse immediately next to or surrounding a specified word or passage and determining its exact meaning (e.g., to quote a remark out of context)”.
  2. And there’s the context we glean through perceptions, meaning “the whole situation, background, or environment relevant to a particular event, personality, creation, etc…”

It’s this second aspect, the perceptual side, which most would agree upon as the meaning of context. Using this definition, our animal friends are “context-aware” up to some level, able to “read” a situation and act accordingly. But we also have the first aspect, language, which allows us to describe the world in sentences, sharing contextual information. So context can be represented by a set of related sentences about a given subject—that’s our “parts of a…discourse immediately next to or surrounding a specified word.” And what makes this especially interesting from my perspective, which begins in the narrow field of security, a “security context” is a set of facts about a given “subject” represented by attributes and relations between entities. As such, a security context can be represented as a subset of first order logic—or by sentences in a limited, constrained form of English.

So if you can find a way to extract information for a given subject from a structured system and represent it as sentences then you are, in fact, extracting the underlying “application” context for this subject. And—drumroll, please—that’s just what we’ve done! Basically, we’ve returned to first principles here at Radiant, devising a “contextual and computational language” method to reverse engineer metadata from an application and represent it in a way that’s as easy to interpret at the human level as it is to execute at the machine level.

Now, this wasn’t my idea alone—if you follow the developments around the semantic web, you know that the idea to semantically encode the web (HTML/text) so that our machines can more meaningfully interpret our descriptions and intentions is based on this same foundation. But standards such as RDF and OWL depend on adoption, which cannot be controlled and is currently confined to a minuscule part of the web. On top of that, they have a different purpose. While they are tagging text the same way than we do—object attribute/verb value or other object—their objective is for machine to be able to interpret these tags. Our goal is bigger: we want to create sentences that are readable by both man and machine. So unless you can read the XML that’s behind RDF as if it were your own language, why not speak in plain English instead, rather than working at the interface level and supporting RDF at the generation phase? But we’ll get to that part a little later on…

From Database Standards to Semantics: Making Structured Data Searchable Across Silos

There’s no single data standard representation in our enterprises—you have vital data stored across SQL databases, LDAP directories, XML, web services/REST, and more. While useful on their own, this “Babel tower” of protocols, data representations, and abstractions makes it difficult, if not impossible, to connect the information across different application kingdoms. Why is this so important? Because each silo offers plenty of powerful contextual richness that we can leverage well beyond the scope of that application.

This is essential because even in the very specialized scope of security, you can’t adequately protect a system of applications if you don’t have a clear picture of what’s really enforced at the level of each application, and how all your applications are interrelated. This is why, despite lots of tools for creating roles and policies, progress in authorization has been extremely slow. The challenge is not just in knowing what you want to enforce—that’s the easy part—you must first understand what exists and what is really enforceable, both at the level of a single application and across a complicated process made up of multiple applications. For instance, when I talk to people in the banking sector about their compliance efforts, what I hear is that it’s not only about defining what they want to enforce, it’s about understanding what they have in the first place.

Context is also vital because this structured data is so valuable. It represents perhaps only 10% of the data in the world, but 90% of the value that we derive from automation. Without structured data, automation would be extremely limited, and the productivity that we derive from automation would evaporate. So wouldn’t it be great if we could understand at the layman’s layer what exists in an application (beyond just forms and interface), and link it to the rest of the infrastructure?

Think about what HTML did for text and other unstructured data on the web, making it searchable, discoverable, and so much more useful. Now imagine your structured data, all that incredible process-driven information and context trapped in application silos. What if we could read all that information, link all that data, and free all those contextual relationships that exist between silos? After all, it’s not only the facts, it’s the links between facts that build up a context. Go back to the etymology we discussed above: “context” is from the Latin contextus and it means the joining, the weaving together.

Again, these ideas are not mine alone—there’s a whole discipline within the semantic web dealing with “linked data,” based on how you could link information once it’s tagged under the form of RDF, which means subject-verb-object or subject-attribute-value. (See my last post for an in-depth look at this.)

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

We covered the key role of attributes in my last blogpost, moving from the blunter scope of groups and roles to the more fine-grained approach of attributes. Now we’re going to take this progression a step further, as we narrow in on my favorite topic: digital context. (If you haven’t already, check out my first two posts on context, where I laid out the roadmap and looked at groups, roles, and attributes.) Our first order today is to travel back to logic class and think about predicates.* But Michel, you’re thinking, what does all this have to do with digital context? Well, one way to describe a context about something is to express it using sentences related to the question. While we will come back to the definition of context in a following post, for now let’s just say that we need some building blocks to express facts about the world, some form of sentences that can be interpreted by a computer, and logic is one of the tools for that.

Subject-Predicate-Object: First Order Logic 101

In my most recent post, we saw how the notions of groups and roles ended up in the increased use of attributes as a way to categorize or define identities. This should not be surprising. Behind this use of attributes lays a fundamental mechanism—a way to represent a simple fact. And it’s the same mechanism that we use when we reason based on the rules of formal logic, which has been in practice forever, or when we represent a fact on a computer (think SQL). In fact, one of the greatest achievements of the early 20th century has been the formalization of logic (needed for mathematic foundation) and computation. This type of logical representation is core to everything we do, as reasoned thinkers and as computer scientists.

But in case you’re a few years removed from logic class, let’s examine this mechanism at work by looking at some very simple diagrams about what we are doing when we associate some attribute with a person or an object, such as assigning a person to a group:

Assigning a person to a group

Or assigning a subgroup to a group:

Assigning a subgroup to a group

Each of these constructs can be summarized by the following diagram:

Subject-Predicate-Object

In this diagram, a fact can be asserted by the notation: subject-predicate-object. In predicate logic (AKA first order logic), it’s conventionally written as predicate(X,Y), where the variables X and Y could be themselves objects (references to entities) and/or values (arbitrarily “quoted” labels belonging to the initial vocabulary of our logic system). For instance, in our example above, the fact that “Jane is member of the product marketing group” can be written as memberOf(“Jane”,”Product Marketing”) and subGroupOf(“Product Marketing”,“Marketing”).

These kinds of predicates are called “binary” predicates and they are quite common. So if there are binary predicates, the astute reader (that’s you!) might well wonder if there are also unary predicates and, more generally, n-ary predicates. Indeed, the unary predicate exists and generally it’s used to assign a label to an entity—so if we want to say that Jane is an executive, you would write it as executive(“Jane”). As for the n-ary predicate, well here’s where you will find the usual “n-slots” notation of entities/tables as they’re used in the relational/SQL world. So we’d see something like this: age(“Jane”, “33”) or employee(“Jane”, “33”,”product marketing”).

Now, if you look at all those diagrams above, you’ll notice they have a direction, an orientation that tells us which entity plays the role of subject, since the object for a given predicate cannot generally be substituted. This translates into a given order for the different slots of a predicate; for example, in the notation age(“Jane”, “33”), the first slot“Jane”is for the person, and the second“33”is for her age. Of course, there are always exceptions where the slots are permutable, such as the “brother binary predicate,” where if x is a brother of y—brother(“x”,”y”)— then y is also a brother of x, which could read: brother(“y”,”x”)= brother(“x”,”y”). But in general order, orientation matters.

The diagrams above form directed graphs and the orientation is essential for preserving the semantics of this representation. After all, saying that x kills y—Kill(“x”,”y”)—is very different from saying that y kills x—Kill(“y”,”x”)!

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

I know I’ve been the Old Man of Novato, ranting about context all these years, but the market, the industry, and—most importantly—the technology are finally evolving toward this direction. For the longest time, it was just me and the usual suspects in academia and elsewhere, muttering in our corners about the Semantic Web, but now we’re hearing about context-aware computing from every direction. While I’ve refined a set of slides on context that I’ve delivered to groups large and small over the years, along with a demo of our Context Browser technology, now seems like a great time to put everything I know down in writing.

Although my French heritage and Math background prefer to start from theory and illustrate through examples, my newly American pragmatic tinkerer side is planning to do a quick roadmap here, then look at examples from our existing systems and, through them, make the theoretical case. It’ll take a few posts to get there, but then, I’ve really been enjoying blogging lately, as my manifesto in response to Ian Glazer will testify. Read it from the beginning, if you’d like a peek into my recent madness: one, two, three, four, five, six.

Context Matters: Where We’re At, Where We’re Headed

We’ve already seen the word creeping into marketing materials, but one of these days—okay, maybe months or years—it’s going to be more than a promise: digital context will be everything. As we get closer to digitalizing our entire lives, we’re also moving toward a context-aware computing world. Now, when we’ve talked about context-aware computing so far, it has seemed like one of those woolly concepts straight from a hyper-caffeinated analyst’s brain (or an over-promising marketer’s pen). But the truth is, any sizeable application that’s not somehow context-aware is pretty useless or poorly designed.

Sure, there are pieces of code or programs that exist to provide some transition between observable states and, as such, are “stateless.” And I know that on the geeking edge, it’s trendy to talk about stateless systems, which are an important part of the whole picture. In reality, however, the world needs to record all kinds of states, because a stateless world also means a world without any form of memory—no past, present, or future. So it’s not like most of our programs and applications are not context-aware. They are, and most of the time they’re pretty good at managing their own context.

The problem is that we move from context to context, and in the digital world this means that unless those programs, those agents, those devices share their context, we are facing a stop-and-go experience where the loss of context can be as annoying—or as dangerous—as an interrupted or broken service. The lack of context integration can mean a bad user experience—or a dead patient due to a wrong medication. In a world where actions and automated decisions can be taken in a split-second, this absence of context integration is a huge challenge. Nowhere is the issue is more acute than in security, in authentication and authorization.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Bonjour, and welcome to the Radiant Logic blog!

My team and I will use this as a place to share ideas with you on directory virtualization, data services abstraction, and other topics, with a particular emphasis on identity and context. Now, you may have heard me talk about context before. You may have even thought to yourself, “context, context, it’s always context with this guy Michel.”

So what does digital identity have to do with context? And what does context have to do with directory virtualization? Well, if you’ll bear with me for a little detour through the world of directories, I think it will all begin to come into focus.

Directories: Plateau, Legacy…and Renaissance?

After a period of high excitement and fast adoption, directories (by that I mean essentially LDAP directories or their equivalent) have reached a plateau phase. Technically, there’s not much happening and to some extent they’re now legacy. At least, that’s what conventional wisdom would have you believe.

In fact, it’s the issues facing the current directories (and the whole data service layer, really)—things like difficult integrations and lack of flexibility—that have driven the trend toward virtualization. I’d compare it to the evolution of OS virtualization. In the beginning, IBM virtualization on mainframe and then VMware and other virtualization layers, was just about abstracting the low level hardware/devices, so that one legacy operating system would coexist with another. As progress was made, better understanding of this virtualization layer brought about the current craze of server abstraction and the move toward “elastic” and cloud computing.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail