Combo field/Multigroup to create one-off complex field tables

I would like to post some thoughts from data design point of view, not implementation or performance point of view.

The problem

Combo field/Multigroup is about common data design problem that concerns some specific kind of data, for example:

• address(street, city, state, postal_code),
• price(net price, vat, currency),
• rental(value, currency, amounts of time),
• weight(value, units),
• date_time(year, month, day, hour, minute, second),
• link(link_text, url),
• email(owner_of_mailbox, url).

This kind of combo data have one specific characteristic: only all parts together makes sense. If just one part of data is missing, then data are senseless or worthless, for example:

• price: 10 (USD? EUR?),
• rental: 100 USD (per year? per month? per day?)
• weight: 5 (kg? pounds?),
• link: Wikipedia (URL?),
• email: me@example.com (owner of mailbox?).

This kind of data MUST stay together. In these examples, the second part of information (currency, period, units, url, mailbox owner) make BIG difference.

Only date and time data types are implemented in database system.

The solution

Because this design problem is very common, there must be some convenient solution. And there is! Let's look at some canonical data model: RDF.

RDF

In RDF our problem can be resolved in many ways. But there are some convenient ways to do this, that RDF can offer:

1. Blank node

RDF can directly represents only binary relationships. So we can't just say:

Person -- address --> "Street", "City", "State", "Postal code"

In such cases we can use blank node. Blank node is a node which is not identified, because it's not expected to be referenced from outside. Here is our example using blank node:

Person       -- address     --> _blank_node_
_blank_node_ -- street      --> "Street"
_blank_node_ -- city        --> "City"
_blank_node_ -- state       --> "State"
_blank_node_ -- postal_code --> "Postal code"

2. rdf:value

The rdf:value is convenient when one part of combo data is considered main value, for example:

• weight(value, units),
• rental(value, currency, amounts of time).

3. Other solutions

From RDF Primer:

There is no need to use rdf:value for these purposes (e.g., a user-defined property name, such as exterms:amount, could have been used instead of rdf:value in Example 21), and RDF does not associate any special meaning with rdf:value. rdf:value is simply provided as a convenience for use in these commonly-occurring situations.

However, even though much existing data in databases and on the Web (and in later Primer examples) takes the form of simple values for properties such as weights, costs, etc., the principle that such simple values are often insufficient to adequately describe these values is an important one. In a global environment such as the Web, it is generally not safe to make the assumption that anyone accessing a property value will understand the units being used (or other contextually-dependent information that may be involved). For example, a U.S. site might give a weight value in pounds, but someone accessing that data from outside the U.S. might assume that weights are given in kilograms. The correct interpretation of data in the Web environment may require that additional information (such as units information) be explicitly recorded. This can be done in many ways, such as using rdf:value, building units into property names (e.g., exterms:weightInKg), defining specialized datatypes that include units information (e.g., extypes:kilograms), or adding additional user-defined properties to specify this information (e.g., exterms:unitOfWeight), either in descriptions of individual items or products, in descriptions of sets of data (e.g., all the data in a catalog or on a site), or in schemas (see Section 5).

CCK perspective

I think that in CCK-world there are many modules that using such design model like Multigroup, for example Link, Email, Money CCK field, Address, Fullname field, and Date. Of course date module make use of data type build in the database, but the idea stay the same. That's why I'm thinking of much better integration multigroup in CCK content module, so other modules could use common API to store their combo data in simply, clear and common way.

There is another disadvantage of current situation which I believe can be better understand thanks to the rule of least power. I mean at present every CCK-related module must define its own way of storing combo data. In result only that module can understand and process these combo data. This shouldn't work that way.

Data should be shared for all modules and be understandable in itself without magic processing by a specific module that created these data. Thanks to this principle, Views and every other module, will "understand" that some data are combo data so should be read/write/update/display together.

Special case: multiple value subfield

Flexibility is a valuable feature, so one could think about this kind of structure:

Record album   -- track     -->  _blank_node_
_blank_node_   -- genre     --> "Genre"
_blank_node_   -- artist    --> _blank_node_2_
_blank_node_2_ -- co-artist --> "Artist 1"
_blank_node_2_ -- co-artist --> "Artist 2"
_blank_node_2_ -- co-artist --> "Artist 3"

In this case:

• artist should be multiple subfield, or
• _blank_node_ should be a real node (not blank node), and track should be node reference.

In this particular example, I think that second solution (real node) is better, because the same track could be available on many record albums.

Summary

I think that idea of blank node is something that perfectly fit for combo data/multigroup. Blank nodes are useful where we need to designate some combo data but in very limited context, because blank node don't have identifier. That's why these nodes are blank.

The same should apply to multigroup. If we really need multiple value subfield in our combo data, then we should probably use a content type, which is a rightful and flexible content container. Multigroup should be some data type like datetime implemented in database systems, nothing more. Multigroup should resolve one specific problem and do it right.

As I said, if Multigrop is about combo data, that must be storing and viewing always together, then implementation is much more obvious.

content_multifield_address table:
+-----+-----+-------+--------+------+-------+-------------+
| vid | nid | delta | street | city | state | postal_code |
+-----+-----+-------+--------+------+-------+-------------+
|   6 |   5 |     0 | Street | City | State | Postal code |
|   5 |   4 |     0 | Street | City | State | Postal code |
|   7 |   6 |     0 | Street | City | State | Postal code |
+-----+-----+-------+--------+------+-------+-------------+

So what is your opinion? What is the best blank node/blank content type implementation? :-) If you have any better (or just different) idea of what multigroup should really be, then please share your thoughts. Thanking you in advance for you comments!

Just FYI: CCK3 is an experimental branch in CCK where Content Multigroup module is available. So you can take a look and see how it works, etc.

References:
- Development snapshot for cck 6.x-3.x-dev.
- State of the Content Multigroup module.