Notes on "Data Centric Revolution"
- Complexity is a problem
- IT is focused on applications, which in turn have their own way of
- This leads to many non-linked data models, hidden away behind
- Objects don’t have a globally unique key
- There is no common ontology (or ontology at all). This means no
connection between all the classes, and their properties
- This also implies that there is little (or too little) code reuse,
because applications and their code focus on their own “unique data
- Become data centric
- Have an upper ontology in your enterprise, reuse an existing but
small ontology where possible, e.g. gist
- Build on this ontology, and extend the ontology as needed in the
enterprise. Don’t create a big ontology. Hundreds of concepts should
suffice, not thousands.
- Have globally unique identifiers for objects (and classes, and
properties). [Think about namespaces]
- Focus on shared data, build applications around it that use that
- Linking different ontologies is allowed, but not ideal.
- Have code handle generic use cases.
- The path is a long one
- Think big, act small - e.g. be useful early on
- Expect lots of company politics, lots of pages in the book are
dedicated to the problem
- Have a small core team that brings stability between projects
Impression and my own
- Good general idea
- The first chapters are a bit repetitive
- The book is a bit focused on RDF (or RDF*), Sparql, federated
queries and the surrounding ecosystem. Can the goal be achieved using
labeled property graphs?
- How would coding for such a system look like? For me, it seems to
imply “duck typing”, e.g. instead of checking for class inheritance one
would need to check if an object matches a certain interface.
- The main issue is making and keeping it all (ontology, code, user
interface) understandable, while at the same time keeping enough
- The book references follow-up books, which are not available