FOAF fields

From LID Wiki

Contents 1 FOAF Classes 2 FOAF Properties

Head page: Modeling LID--The objects of the model

Now, since we started with the NetMesh Property model, and FOAF is built using RDF, the modeler demon tells me to go back to the NetMesh Foundation model and start over from there. But the planner demon sits on the other shoulder and tells me to stick with the plan. For now, i'll stick with the plan.

I'm just reading through FOAF Vocabulary Specification and using this page as a workspace. At this point the difference in where-it-is-coming-from between vCard and FOAF comes to the fore.

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 <a href="http://netmesh.info/jernst"> Johannes</a> 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.

 organization

Now, this gets interesting. This organization is quite different from the orgName listed at vCard fields. vCard::orgName (if i may be allowed the notation) is anIdentityDataItemType. foaf::Organization (aka foaf:Organization) is an object type: it has the same status in the FOAF model as foaf::Person. And foaf::Person corresponds to the vCard lurker (the person whose vCard a particular vCard is).

Coming at this from another angle, a vCard contains the name of an organization, while a FOAF document contains a relationship to another object, where we find the name of that organization as a property of that object.

So we have two differences here. One is that a vCard contains the name of the person's organization directly, while a foaf:PersonalProfileDocument (or maybe i don't know what that is: let's start over) One is that a vCard contains the name of the person's organization directly, while a FOAF document specifies a relationship to an organization document that contains the name.

The more interesting difference is that the structure of the model behind FOAF is richer than that of the model behind vCard.

Clearly, the identity data part of a model of LID will both want and need the richer structure. By making the concepts of the initial model, which was built looking at the vCard specification, be concepts about data (e.g. IdentityData), we kept the model clear for objects that represent things.

 basedNear

Since we are not here to criticize our betters, i bite my tongue and withold comment on the theory of foaf:based_near.

To the point of this text, however: This is an interesting contrast to the previous example of organization. foaf::basedNear is a FOAF property. Thus, it corresponds nicely to vCard::latitude and vCard::longitude.

As does vCard, FOAF lacks a concept of place. But, because of the architecture of FOAF, this problem (if it is a problem) is tractable: one need only choose an RDF namespace that has a useful (or, anyway, usable) concept of place.

FOAF Classes

The stable FOAF classes:

 Person

FOAF classes that are in testing but are stable enough for our present purpose:

 Document
 Image

FOAF classes that are unstable but will be incorporated in the model:

 Organization

All the FOAF classes, stable, testing, and unstable; interesting and boring:

 Person

 Agent
 Group
 Organization

 Project

 Document
 PersonalProfileDocument
 Image

 OnlineAccount
 OnlineChatAccount
 OnlineEcommerceAccount
 OnlineGamingAccount

FOAF Properties

The stable FOAF properties:

 homepage    (different in meaning from vCard url?)

 eMailAddress

The FOAF properties that are in testing and interesting:

 name
 familyName
 firstName
 givenName
 nickname
 surname
 title

 knows

 interest

 made

 phone

 eMailAddress
 eMailAddressChecksum
 jabberID
 blog

 image
 depiction

 logo

 plan

An alphabetical list of all the FOAF properties:

 accountName
 accountServiceHomepage
 aimChatID
 based_near
 birthday
 currentProject
 depiction
 depicts
 dnaChecksum
 family_name
 firstName
 fundedBy
 geekcode
 gender
 givenname
 holdsAccount
 homepage    (different in meaning from vCard url?)
 icqChatID
 img
 interest
 jabberID
 knows
 logo
 made
 maker
 mbox
 mbox_sha1sum
 member
 membershipClass
 msnChatID
 myersBriggs
 name
 nick
 page
 pastProject
 phone
 plan
 primaryTopic
 publications
 schoolHomepage
 sha1
 surname
 theme
 thumbnail
 tipjar
 title
 topic
 topic_interest
 weblog
 workInfoHomepage
 workplaceHomepage
 yahooChatID