Joaquin Miller's Blog

What do you mean, unidirectional, exactly?

It is greatly to be desired that Alice can create an identifier with this quality: She can use it in her business with Company, and no one can correlate what she does using that identifier with anything she does using some other identifier.

An identifier that has this quality is sometimes called a "unidirectional" identifier.

I'll make some claims (pun intended) here, looking forward to being corrected where i am missing something or am dead wrong.

There is no general agreement on what 'unidirectional' means.
One meaning, intended by some who use the term, is that a) the unidirectional identifier is used with by Alice with only one party, b) another unidirectional identifier is used by Alice with another party and c) there is no information in the two identifiers that can be used to determine that the same person is using both identifiers.
Another meaning, intended by others, is that a) the unidirectional identifier is used with by Alice with only one party, b) another unidirectional identifier is used by Alice with another party and c) there is no information that can be used to determine that the same person is using both identifiers.
I hate to write "Let's use these terms just for this argument, please," because the next thing we know these terms will be used in other contexts.

Let's use these terms just for this argument, please: For the meaning in 2), let's use 'weakest-unidirectional' and for the meaning in 3), let's use 'strongest-unidirectional.'
Identifiers having the weakest-unidirectional quality are trivially easy. There is no information in these two identifiers that can be used to determine that the same person is using both identifiers:
```
   http://www.joaquin.net/pseudonym1
   http://www.joaquin.net/pseudonym2
```
(Please do go ahead and contradict that. There are two possible outcomes: a) You demonstrate that i'm wrong. b) You agree that what you saw as information in the identifiers was not enough; that you do need more information, not in the two identifiers, to determine that the same person is using both identifiers.)
No identifiers have the strongest-unidirectional quality.

(Please do go ahead and contradict that. This could be real interesting.)
In the absence of continuous reliable surveillance of a person, it is possible for that person to use identifiers that have the almost-strongest-unidirectional quality.

So: What do you mean, unidirectional, exactly?

Person and Persona

At the LID developers' Wiki, I'm using the page, FOAF Fields, as a workspace as i'm reading through the FOAF Vocabulary Specification. A few minutes ago, the difference in where-it-is-coming-from between vCard and FOAF came to the fore. I take this occassion to offer some thoughts on the concepts, person and persona.

Wiki enables your feedback and ideas to be entered right there, by changing or replacing my text. Or by entering text at the discussion tab.

Or, if you are more blog than wiki, kindly blog and link back to here.

In vCard, that a vCard is the vCard of a person is implicit. Just as it is implicit, if we see a small paper card, about two inches by three and a half, with a name on it, that this is the calling card or business card of some person, and that other data on that card gives us information about that person and their relationships. Just as a person may have different business cards for different roles, so two different vCards can be vCards of the same person. But the vCard specification gives us no way to relate those two vCards.

One datum on a vCard is related to another by being within the same vCard. (Yes, or by being somehow linked to from a vCard, but forget that for this discussion.)

One datum in FOAF is related to another by property connections to an object.

A concrete example:

With vCard, organization is a text field, giving the name of the organization. We know 'NetMesh' is the name of the organization of Joaquin Miller, because we find it in the org field of a vCard and 'Joaquin Miller' in the formatted name field of that vCard.

With FOAF, instead, we know NetMesh is the organization of Joaquin Miller, because we find an organization link to an organization object with 'NetMesh' in the name property from the person object with 'Joaquin Miller' in the name property.

With vCard, we can't tell that Johannes is associated with the same organization as Joaquin. Perhaps there are two organizations with the same name, one headquartered in sunny Sunnyvale, and the other with address in foggy on a summer morning East Oakland. FOAF lets us know that this is the same NetMesh.

So you conclude FOAF is better? Let's judge goodness while considering intent. And let's not rush to judgement.

Permit me to go down this rabbit hole just a bit deeper.

Suppose one person has two vCards. Consider two cases:

Case 1: One vCard identifies the person as Deputy Assistant Undersecretary for Personas of the Department of Homeland Security, USofA. The other identifies that person as Member, Board of Directors, Society for Calming of the Polity. In this case, we have one person, with one {identity | persona | whatchewmightcallit}, in two roles, with a vCard for each role.

Case 2: One vCard identifies the person as Reporter, Daily Planet, Metropolis. The other identifies that person as Man of Steel. In this case, we have one person with two distinct and (except for we readers) unrelated {identities | personas | whatchewmightcallits}.

For vCard, these two cases are like water off that famous duck's back. If the first person profers two vCards, we all understand what is going on. (Someone might want to have a look at the law, to check on the limits on outside activities of officers of the government.) If Lois finds a copy of Superman's vCard on Clark's computer, that does not prove anything.

On the other hand, vCard has no way to link the two vCards in the first case and, therefore, no way to keep them separate in the second.

For FOAF, the identity data is linked to a person object. The first case is handled nicely by linking two sets of identity data to the same person object. (I don't know enough about FOAF yet to know if there is a mechanism for preventing the two sets of data from being jumbled. We can't have donors delivering money for the Society to the office of the Deputy Assistant Undersecretary. Well, we can and may do, but that's illegal, so it will be useful to avoid the jumble.)

The second case, on the other hand, is a problem for FOAF. If we believe in the semanticity of the web, then foaf:Person represents a person. FOAF groups the reporter's contact data as properties of the foaf:Person object representing Clark. How to group the man of steel's contact information, in case we need his help in dealing with the present situation? We can't group it using the object representing the reporter. But: if we group it using a different foaf:Person, we are lying and, more to the point, violating the FOAF specification.

Not to worry. Our LID model will deal with this. For now, though, we put aside these considerations and proceed with the project as planned.

A successful test!

The first test of the initial LID model is to use the model to represent the examples of vCards provided in RFC 2426. The first step of this test is to prepare the test cases by making a list of the examples in the RFC. While making this list, your humble tester was reminded that a vCard may include another vCard. The initial model failed to provide for this.

To correct this error, I changed the model, following the GOF pattern, Composite: I made IdentityData a subclass of IdentityDataItem.

Modeling LID

Modeling LID--The classes and associations of the model

Modeling LID--Testing the model

Remember folks:

"Testing is the process of [using a model] with the intent of finding errors."

    Glenford J Myers
    The Art of Software Testing
    ISBN 0-471-04328-1

Modeling LID

At the LID developers' Wiki, I've added a page, Modeling LID, where i have entered the rough beginning of a project to build a model of identity data.

When this project reaches a stable state, that page will provide an overview of that model and links to detailed specification of that model. For now, it amounts to thinking out loud. So, that page violates the guideline that wiki pages should be short. Wiki enables your feedback and ideas to be entered right there, by changing or replacing my text. Or by entering text at the discussion tab.

I'll blog a bit here about the modeling considerations that go into this model.

Schneier Blogs

Because of the importance of security, i mention here: Bruce Schneier announces: "Blog: Crypto-Gram is now available in blog form. Called "Schneier on Security," the blog will have the same content as Crypto-Gram but it will be posted continually rather than only on the 15th of the month. Initially, blog comments will be turned off. I'll enable them as soon as my anti-blog-spam software is working. "RSS: The Crypto-Gram RSS feed has been working for about six months now. Current RSS subscribers will receive the blog version of Crypto-Gram instead of the once-a-month version." See http://www.schneier.com/blog/