crherlihy
commented
5 years ago I agree. We need to think about whether it makes sense to combine them, and if we want to combine them, how/why/for what use cases (as the preferred answer may vary by use case).
For the last deliverable, I handled schema unification from code + markdown in the extract script, but to integrate all the disparate pieces, we need a standard api, reasonable defaults upon ingestion in cases where the type (of either vertex, and/or the edge) is not known, and a strategy for asserting semantic <-> code links. It may be helpful from a modeling perspective to think of this as a domain-specific translation problem. Controlling for reserved words in a (programming) language and domain-specific keywords/n-grams as identified by part of speech + frequency of occurrence may be helpful. This strategy should inform and be informed by a (revised) version of our original schema. Revisions are necessary to ensure relationships are functional if we decide to leverage category theory in the ways we have discussed.
It seems to me what might be helpful are collapsable levels of precision that could be interpreted/experienced by the end-user as filters on the graph.
jpfairbanks
We need a strategy for how we are going to leverage each of these different knowledge graphs. Some of them have nice category theory principles behind them (ie. type and data flow graphs) but others are somewhat ad hoc. The combination of the dataflow graph with the type graph seems to be a productive avenue for further research. But I am not sure how to preserve the precise semantics of each graph while productively combining them. Maybe category theory holds more answers here.