Maja-O. L., we have found the same issue, though we visualize the "data" that is in the graph in a "knowledge store viewer" that sort of feels like a wiki - but only in that entities represent what would be "pages" in a wiki, but it is anything but a wiki - as the whole GUI interprets the knowledge store ontology live - so the GUI doesn't understand an object specifically, but uses the ontology to "know" how to display it. We allow plug-ins for specific entity types that allow different visualizations for a person versus a place versus a vehicle for example if one doesn't want the basic "this is an entity in your knowledge store, with your relationships: generic view. For us, we wanted an EASY way to deal with the class definition - without the data blowing up the display. We like to keep the data separate from the definition. We don't find any of the current editors very friendly to support this. Let me know if you find something different in your research, and we will do the same. Have you looked at OWLGrEd Ontology Editor? An interesting concept in some ways.
Ditto François S.!
François S., the mesh article is interesting. We have been calling the semantic constructs (that are more aligned than I thought they would be) a "Knowledge Mesh" for several years now. While I agree with many elements she brought out, it still comes down to this: "The key for an effective correlation of data across domains is following certain standards and harmonization rules. Such standardizations should belong to a global governance, to enable interoperability between polyglot domain datasets." One major concern - while she doesn't want the accidental silos, obviously, a person looking at their own requirements without looking at the greater need will create a... silo. So, it is also a culture/training issue. Also, it is great to wax poetic about creating the various interfaces for accessing data, and productizing data, but if they use their own tools and own ideas, (again, not thinking big picture, or greater good) they will NOT align. Thus enters governance. But I advocate that there is governance and training. Getting everybody to think "data as product," clean layering, when standards make sense, appropriate API designs and versioning (yeah, that is a thing - pushing data to APIs still means that the APIs can change or data behind them change - thus other forms of appropriate version control management are still necessary to ensure appropriate data flow when other domains desire to reach out and get your data). And of course - a centralized repository to register your capabilities. Sound familiar? Same for web services - make use of things that work. 🙂 The military has been doing this for years - believe it or not. Take a look at the Content Discovery and Retrieval (CDR) spec. Before that, they had/have the DCGS Integration Backbone (AKA Distributed Common Ground System/Station Integration Backbone, AKA DIB). It was/is a distributed system that defined standards for how to shape data you want to share - regardless if you are Army, Navy, Air Force, etc. -, provided a discovery mechanism so that others could discover your juicy data, and it allowed the domains to completely control their data, keeping their own database, format, structures, etc., only the "interface" required shaping the data you want to expose (creating data products). Some forward thinking that has proved quite successful. Good discussions!!
Agreed, we are seeing that "ontological commitment" issue as well - though seeing agile governance and other best practices using layered ontologies solving this. The top and mid-level ontologies are fairly stable, so much easier for the orgs to create their own child ontologies that just have to link up to the intermediate concepts (keeping the "schema" size manageable for the upper and mid-level ontologies).
Sorry about the long post!
I enjoyed reading your post, but while reading some of the comments in this thread, it was kind of off-putting to have you call Deloitte a scammer (look up your “malinformation” meaning). I appreciate passion in one’s beliefs, but…. You can certainly disagree with what they said in that marketing slick (key word: marketing) – that is fine, but then you will allow me to not fully agree with what you said? There are merits in what you say in the article, just as there are merits in what Deloitte says in the marketing slick. Yours seems to favor smaller, silo thinking (not making that as a negative – just trying to find a way to characterize for the discussion), Deloitte’s more of a “one ring (knowledgebase) rules them all.” Both can be successful (yes, this means we are not in complete agreement of your negative view of centralized potential – or means to achieve it), but both have consequences. Believe it or not, I have heard your same arguments used against other technology approaches – such as content management systems (and document management systems before them) when they first came to the market. You seem to take an either/or approach to this. Yet don't you require data from various data sources to make your approach work? Doesn't that mean connecting all that data together? Lots of data wrangling/mapping/transformational (chose your vernacular) tools have been created over the years (full markets have sprung up around them) to attack this rather nasty problem. I have been in a few industries, and helped solve automation problems for many industries, and do you know one of the biggest challenges myself and my team(s) faced no matter the industry? Getting that data and keeping the connects stable. That is hard, and the connections are fragile at best. Some of the best automation solutions that we assembled were because we took on that pain of connecting those data sources together, and then invariably end up getting a tech support call because something stopped working. Time and again, the trouble shooting came down to the same problem – something in the data changed because (for example) the owner of database “X” decided that they did not need that piece of data anymore, or they changed their API, or, or, or. Data was ALWAYS the problem. Sure, throw in some culture – “I don’t want to share my data with you” and that is reflected onto the data. Don’t get me wrong, I don’t disagree with you -- I just don’t completely agree with you. I think there is some middle ground. Some of our most stable enterprise automation systems had governance (oversight). Yes, a central authority that helped manage data disputes. Probably why the Chief Data Officer was invented – the cost for the data wild west was just too much on organizations. Were they draconic? Not always. Many really were looking out for the greater good – trying to make all the siloed organizations more successful by letting them have their own processes, but those processes tied into the larger organization’s processes via well defined data sharing gates – yes, defined by the central authority – but that was their limit. They helped make that overall information sharing a reality. It usually wasn’t restricting or limiting to the individual organizations, it actually helped them! They knew they could ask for and receive their needed data in a consistent and stable manner. They had well defined entry and exit points for their data (and services) so that the rest of the enterprise could smoothly function, and they actually enabled better automation across the organization. Enter Graphs/Ontologies/RDF – oh my! Now I could help define those gateways in a machine readable/understandable way. This significantly reduced my data maintenance headache (yes, with an initial cost – but far, far less then the alternative of on-going data nightmares). It also allows a different form of automation – the ability for a machine to help me find the right data. Such a cool concept. Did I need the one knowledgebase that rules them all? Not really, but I might have a centralized store for defining the ontologies that are shared so that I have one source for the truth of defining what and where the data is. But that isn’t all the data, just the models. Nice, middle ground. But I could also advocate for a central repository of vetted knowledge – something that has world-wide access, and because of this, it actually prevents data from becoming stale, because instead of 14 copies of that data in several different silos, I have multiple people referring to that single source of truth, keeping it up-to-date, and continuously building it (not individual documents, but truly a knowledge system. Is that the solution for everybody? No, not at all. But for certain applications, it can provide a tremendous boost in knowledge management while reducing cost in the form of duplication errors, multiple people doing the same thing, disconnected knowledge threads, etc. So, I’ve found over the years – the right tool for the right job. And sometimes, a central authority is the right way (and I have seen it work!), and sometimes, highly focused, team/group/organization-based solutions is the right way. Folks in this thread have already brought up examples of how standards can work (some middle ground again). You want better rankings because it will improve your sales? Well, read up on the defined standards or best practices to make sure your web site (data) is aligned to be processed in the best possible way. Standards are a good thing – as long as they are not misused or abused. I do like that old adage – everything in moderation. 😊
Ellie, where do you get all your energy? 🙂 Seems like an interesting roundtable!
