Hi there! I am new to knowledge graph. To create an expert driven knowledge graph, i.e. to model the knowledge in a certain industry, how to scope the project such that we don鈥檛 end up with a project with no end in sight? In theory, there is no limit to knowledge and hence the size of the knowledge graph. Thanks.
great question! Matthias S. will have a thought or two
Goh Kian Leng I am not an expert there as I am learning as well. But I have asked your question quite a few times and the sentence that I hear quite a lot (I think it comes from the data.world fox) is "don't boil the ocean". If I get it right it means to start small. Chose one specific use case, one specific department within your company, with one specific goal and you'll grow your KG from there. The Semantic Arts fox taught me an approach in which you start with a few competency questions (i.e. a few questions you should be able to answer with your KG) a list of the concepts your want to represent. Only then you can start modeling your KG. I don't know what is your knowledge in that field but so far I got mine through these resources:
https://www.morganclaypoolpublishers.com/catalog_Orig/product_info.php?products_id=1252 (technical about ontology modeling for the enterprise)
https://www.youtube.com/channel/UCZsTDApBUUdUpg024K33YNA (great videos about KG with a lot of them from a non technical point of view)
https://www.morganclaypoolpublishers.com/catalog_Orig/product_info.php?products_id=1564 (more with a semantic web point of view)
And there are a lot more resources out there along with way more experienced people in this community 馃槈 I hope it helps get you started :)
Matthias S. Thanks! I will check out the links. I guess it is a prudent approach to start small and grow KG from there. The problem is in most organisation including the one I am working for, we need to put up a business case with definite funding, scope, resource and timeline before embarking on the project. Unlike more traditional projects, it is a bit more challenging to define the boundary of KG project.
Again not an expert there but I feel like defining the scope of a KG problem is not harder than other projects. Or I would say the other more traditional projects give you the illusion that you know how to scope it. That is my point of view heavily biased by these readings 馃槈
For scoping your projetc I would suggest reaching out to the Semantic Arts fox, the are true experts in the field 馃槈
Hi Goh Kian Leng, this is a topic I examine in my book "Semantic Modeling for Data" https://cutt.ly/3fZxxI1; you can also check the following slides: https://www.pldn.nl/file_auth.php/pilod/7/72/D_20200122_Alexopoulos_-_Knowledge_Graph_Strategy.pdf http://www.panosalexopoulos.com/wp-content/uploads/2018/06/ESWC2018Tutorial_ExecutingKnowledgeGraphInitiatives.pdf
you may find some insights over there : https://www.omg.org/cgi-bin/doc?omg/2020-09-03
Thanks for the shout-out Matthias S.! Yes, Goh Kian Leng, its a tough question but the best advice is to always start with the question "what are you trying to find/learn?" from your data? That helps scope the project to be manageable. It is VERY easy to try to boil the ocean in graph, so start with something you can get meaning out of quickly to learn and shape your thinking.
Goh Kian Leng, correct me if I'm misunderstanding, but it sounds like the trouble is with the first step, of defining the business use case?
Hi Goh Kian Leng, your project should identify the stakeholders and target their needs. I have learned over the years that it is important to start with a crisp and clear business problem(s) and to identify the stakeholders of that problem and their expectations. Sometimes, you might have to bring down their expectations but that's ok. This way you will end up with a list of items to address in your work that you can prioritize (narrow down the scope of work) and then take step-by-step approach to solve them. Keep your stakeholders in the loop for priority change or new ideas. This way you can avoid being stuck with a project with no end in sight.
Hi Ellie Y., yes the issue is with the first step, how much the project will cost and how long it will take. Mapping out knowledge can take a life of its own to become an endless thing.
there's a quote I hear a lot in this space: "a little bit of modeling goes a long way." to make projects workable, it's best to start with defining exactly what knowledge is needed for the immediate use case/project (which can, in next iterations, become larger), and focus on that. And to figure out what those are-- Michael A. may have some guidance here.
Goh Kian Leng, if you are up for it, we could start a conversation thread to discuss or set up a call. I find having a person to talk it out with is often the most helpful way to get your own ideas in order. Let me know! I would be happy to lend my ear
Goh Kian Leng, I ran your question by Paco N. -- he had a few initial thoughts: "We can discuss and help turn something that seems intractable into almost an outline or high-level project plan.聽 Modeling the knowledge in an entire industry vertical is聽LOTS聽of work, although probably (98% sure) when we discuss in detail the person asking is probably interested in a much more specific project." He's my guest for Office Hours tomorrow, so feel free to come and discuss further with him. Here's the link to join (11 am EST): https://tinyurl.com/y52skc6v
Goh Kian Leng It would seem like "no end in sight" at the start of these projects -- I can empathize. I'd suggest a best practice for this is to start with a simple list: what are the top "things" in your business which (1) are important for your work and (2) for which you can state a clear, concise definition with full agreement across your team. In my experience, when people are looking closely at the details of their organization, that list starts out relatively brief. Those are the kernel from which to build out your plan for how to add more. For example, in our company after being in business for +2 years, initially we could define 6 things that are important for our work to be clearly defined, and which our partners and clients would also also completely agree. Then we added some topic areas, initially about 8 of those -- all of which could be linked to formal definitions elsewhere. Any more, at the first stage, would have created lots of confusion and overlap, so we kept that succinct. Oddly, when we began to use that controlled vocabulary for one use case in our content management, we only had to add a couple more definitions to get full coverage. So start small, add carefully, and the problem is probably not a "no end in sight" circumstance.
