Deep-dive into data representation with the Property Sheet Viewlet (OPTIONAL)

/docs/developers/tutorials-mesh/docker-mock/propertysheet-facebook-mock-data/

Introduction

In this section, we will use the Property Sheet Viewlet:

This tutorial assumes you have successfully imported the mock Facebook data as described in Importing (mock) Facebook data into the UBOS Personal Data Mesh.

Understanding what’s shown on a Property Sheet Viewlet

Open up the message from Lisa Nelson in the precending section again (its URL is http://localhost:1080/%5bfacebook.com/user/William%20Smith%5dmessage/lisanelson_mtudvy2-zq/1251261270000).

Click on “Views” and select “Properties”.

After the “Property Sheet Viewlet” has come up, look at the URL in your browser. You may notice that the URL is the same as before, but with an extra argument. This extra argument indicates that we want top use a different Viewlet than the default, in this case the “Property Sheet Viewlet”.

The “Property Sheet Viewlet” is both the most inscrutable, and the most useful Viewlet for developers, because it shows you how data is natively represented on the UBOS Personal Data Mesh. Think of it as the assembly language view of personal data.

Let’s examine it section by section:

The header area

The headline shows the MeshObjectIdentifier as the headline.

Insight

Each MeshObject has a unique MeshObjectIdentifier, which is immutable over the lifetime of the MeshObject. It is generally mapped directly to the URL in the browser that accesses that MeshObject.

To the right, we have the times the MeshObject was created and last updated. These two values are automatically maintained by the UBOS Personal Data Mesh.

Insight

The UBOS Personal Data Mesh keeps track when each MeshObject was created and last updated.

EntityTypes and Properties section

Let’s define two terms first:

Insight

An EntityType for a MeshObject is similar to what a class is to an instance in programming: it defines some semantics, and typically a structure.

An EntityType may define one or more PropertyTypes, similar to how members (or fields) are defined by a class. Each PropertyType has a name, and comes with rules about what values a MeshObject can hold in that property. However, compared to a typical programming language, PropertyTypes can define far more detail about what values are permitted. For example, an integer PropertyType can specify permitted minimum and maximum values, like 5 or 7. (More about this later).

All MeshObjects blessed with an EntityType will have one slot for each PropertyType defined by that EntityType, as you would expect in analogy with classes, members and instances.

This section in the Property Sheet Viewlet shows the MeshObject’s EntityTypes: here the EntityType is “Facebook message”.

In the rows below, each of the PropertyTypes of “Facebook message” is listed, with the value that this MeshObject carries for each PropertyType. This is how this “Facebook message” object carries the content of the message, the subject (which is not set in this case) and other fields.

If you hover over “Facebook message” or any of the names of the PropertyTypes, a tool tip will show you the MeshTypeIdentifier, which is a unique identifier for this particular MeshType. You often use MeshTypeIdentifiers in programming to refer to the MeshType you mean. What’s shown here are the fully-qualified names: they come with scope, because Models – which is where EntityTypes, PropertyTypes etc are defined – can be defined by developers like you, and name conflicts would be a bad idea.

Attributes section

This section is empty for this MeshObject.

Insight

Attributes are a free-form version of PropertyTypes: you can arbitrarily add Attributes to any MeshObject and there are (almost) no rules about values for them.

There are useful for prototyping, and attaching short-lived information to MeshObjects.

If you like, you can click on the little + next to “Attribute name” and set an Attribute with some name and String value right there.

In fact, if you hadn’t noticed, you can change most data on the UBOS Personal Data Mesh right there from the Property Sheet Viewlet. This makes development quite simple, too, because you can easily try out how your code is behaving with different data values that you can enter right in the GUI without writing any new code.

Insight

All information on the UBOS Personal Data Mesh is can be edited by the user (if the current Viewlet provides a UI for it; the Property Sheet does.)

RoleTypes and RoleProperties section

Note that there is more than one table in this section. Each table has a headline saying “Neighbor” and a clickable MeshObjectIdentifier.

This section shows you how the current MeshObject is related to other MeshObjects: we call them neighbors (in a graph). You can click the neighbor and thus traverse to it.

Below each neighbor, the type of relationship with this neighbor is shown. Distinguishing types of relationships, and their direction is useful: it lets us distinguish, for example, whether Alice and Bob, if they are neighbors in the graph, “love” or “hate” each other, or that Alice is Bob’s landlord. All of them would be examples of relationship types.

In many ways, the concept of relationship type is to a pair of MeshObjects what an EntityType is for a single MeshObject: it defines the semantics of the relationship, and potentially a structure. So the layout in the Property Sheet Viewlet is rather similar.

It’s important to not mix up a relationship’s direction. There is a big difference whether Alice is the landlord of Bob, or Bob is the landlord of Alice! So instead of relationship types, we typically use the concept of a RoleType. A relationship type is made up of two RoleTypes, which you can think of as the source and the destination of the relationship type. By using a RoleType, instead of the relationship type, in the API and in the user interface, we know not only what relationship type is meant, but also which direction.

Going back to the Property Sheet Viewlet, the name of the RoleType is preceded by an arrow that either points forward or backward. It indicates how the relationship is directed.

Remember that the current MeshObject is a Facebook message. Here “=> created by” means that the current message was “created by” this particular neighbor MeshObject. (If you click through to the neighbor, you see it is a “Facebook account”, meaning that this particular message was created by that particular Facebook account.)

In the second table in this section, the arrow points the other way, meaning it should be read the opposite way. The neighbor MeshObject here is a “Facebook message thread”, and so the relationship reads “This facebook message thread (the neighbor) collects this message”.

Insight

MeshObjects can have (any number of) neighbor MeshObjects. The connection between them may be blessed with one or more RoleTypes, which indicate the semantics and the direction of the relationship.

Like EntityTypes, RoleTypes can define PropertyTypes (and RoleAttributes see next section), which allow you to attach values to the relationship between two MeshObjects. (This is somewhat uncommon, but very handy when needed.)

Role Attributes section

Finally, RoleAttributes are to RoleProperties as Attributes are to Properties.

Insight

RoleAttributes are a free-form version of PropertyTypes on RoleTypes: you can arbitrarily add RoleAttributes to any pair of MeshObjects and there are (almost) no rules about values for them.

There are useful for prototyping, and attaching short-lived information to MeshObjects.

Next step

Let’s add some (mock) Google data, and watch a Bot connect the Facebook data and the Google data into a single, multi-service address book, by going to Adding Google data and watching a bot connect it to the Facebook data.