You can only get an eye-opener if you have your eyes wide open. Only then can you observe the world deeply and detect things or patterns that are hidden. This is particularly true for content modelling.
As the name suggests, content modelling is about modelling the content – not the world.
The affiliation example
Take "affiliations". One can take the view that affiliations in a database are modelled incorrectly, because an affiliation is a relationship that connects a person to an organisation. It is tempting to apply this knowledge of the world, and you will get a lot of support from colleagues who agree. But what we call an "affiliation" in our content is often not an affiliation at all. It can be a job title. It can be multiple affiliations in one string. It can be just a street address. It cannot always be tied to any specific author in the article.
Following what we know about the world instead of scrutinising the content will create an even worse model. We know this mistake was made in funding data schemas: modellers imposed a clean logical structure on data that is inherently messy, and the result was a model that fit the ideal world but not the content.
Edge cases are the real test
Content modelling requires a passion for edge cases, and even corner cases – places where two or more edges meet – and curiosity about the actual corpus.
In my experience, for every colleague who finds an edge case exciting there is one who finds it boring. The latter group tends to be less suited to content modelling.
Edge cases I have encountered in practice: an author whose name contains a question mark (yes, really), who also has had a gender change. A document authored by "Bill and Melinda Gates" – which does not contain "Bill Gates" as a substring. A conference paper whose full reference list appears in the frontmatter of the volume, not within the chapter. These are not theoretical; they exist in any large corpus.
Markup in linked data
In our context, some limited markup is allowed in content fields – sub- and superscripts. This is a challenge when moving to linked data, because it fits with the world of HTML, not with the world of JSON-LD.
The right approach: when we expose content through a context view, the HTML presentation layer can have all the richness it needs. The linked data layer connects assertions about the content to the content. The linked data user is not interested in the markup, and will not be processing JSON key-value pairs through an XML processor. The linked data user needs clean, true assertions.
Every assertion that is not true pollutes the knowledge graph. Our objective is to create the best knowledge graph – one where every assertion is true. Owing to the limited nature of markup in older schemas, the fields we have are already a distortion of the real titles and abstracts. What the XML is telling us in those cases are false assertions that should not be allowed into the knowledge graph.
The ground rule "no data left behind" should not degenerate to "no garbage left behind" out of fear that we might lose something – something that is mostly wrong. Let us serve the linked data user with proper linked data. The content presentation layer will come; it is important, but it is less urgent than getting the assertions right.