The problem

There are an ever increasing number of social networks out there, all of which seem to make the end user run around in ever decreasing circles, re-entering the same data for the fun of it (well, that's how it looks!) and generally making life a pain for the end user.

Massive amounts of data are generated without any real thought going into it - the reason why is simple enough. When the original concept for the database schema was thought up, it was probably written on the back of a paper napkin and just shoved into an SQL database without much thought to future expansion. This would certainly account for why a user on the likes of Facebook has to enter extra data every now and again

The real problem

In reality, the problem isn't really that. The problem is that people don't think like computers - they think like people. Take something simple - like a book. A book will have certain properties such as the author, year of publication, publisher and so on. We understand these properties as we're used to them. A computer doesn't. Below demonstrates this problem

Computer understands People understand
  • Strings (names)
  • Numbers (integers or real)
  • Dates
  • Name of the author(s)
  • Publication date
  • Publisher details (including an address)
  • Edition
  • ISBN number
  • Published language
  • Price

The human to computer problem

While as a species humans can understand a multitude of different things and just accept what they are (in my example, a price can be in any currency going, it's just accepted as having a monetary value), in the computer domain, things are greatly different.

If publisher details is taken as an example, it can be seen that the details may or may not include an address. Addresses, depending on the country can be 3 lines long or they can be 6 lines long. The postcode in different contries are in different formats, they may have an email address, phone number, fax number and even different offices around the world. To your average chap in the street, they think nothing of it. In computer terms though a balance has to struck between the number of lines of the address, the format of the postcode and so on - the reason being is space. Each line of text has a certain number of characters reserved for it - makes no difference if there is something in the line or not - the space is reserved.

Each publisher has to be "linked" back into the main schema (a relationship) which may or may not have a speed hit (depends on the size and complexity of the database).

A user will normally want to search the database for something in particular - again, this will take a hit if it's not handled correctly

The list carries on and on and on and well, on.

We are not computers

The Dublin Core system is a very simple way of humans understanding data - the implementation of the system is down to whoever writes the code - the schema though is simple enough

The most important aspect of the Core is to decide if something is literal (free text - a pile of words) or non-literal (not free text - constrained by protocol)

Parameter Literal / Non-Literal
  • Name of the author(s)
  • Publication date
  • Publisher details (including an address)
  • Edition
  • ISBN number
  • Published language
  • Price
  • Non-literal (See notes)
  • Literal (dates have different formats)
  • Literal (an address has many lines)
  • Non-literal (fixed)
  • Non-literal (fixed - 1, 2, 3 etc)
  • Non-literal (fixed - from publisher)
  • Non-literal (fixed - RRP from publisher)

The name is slightly odd in all of this. Names typically have two parts - first name and family name, but as will be seen, this is where the Dublin Core system hits a problem....