3 ms·
There are 5 practical relationship roles in knowledge modeling: parent-child, associate, source-target. Parent-child is hierarchy. Associate is undirected peer
by wenc 7y ago
There are 5 practical relationship roles in knowledge modeling: parent-child, associate, source-target.
Parent-child is hierarchy. Associate is undirected peer. Source-target is less useful in general, but it roughly represents a directed peer relationship (e.g. A exports this good to B, and B exports that service to A -- there's a direction).
Associative relationships are very easy. Bob is friends with Mary, and with Pete. But they are also very loose and do not convey any information around belonging/precedence/ordering, which is a major downside. Associations don't have sufficient representational power for capturing structures.
Hierarchical relationships are very useful for expressing structure. For modeling real knowledge, you also need the ability to represent multiple hierarchies. For example, Bob is Dan and Chloe's father (parent-child in one context), and Bob is also Beth and Joe's boss (parent-child in another context). It can also happen in reverse -- Beth is Bob's superior in a social club they both belong to (yet another context). Multi hierarchies appear everywhere yet we don't often recognize them as such.
Multiple hierarchies are sometimes captured through tags (e.g. Gmail categories) or in the UNIX file system, via symbolic links. But apart from those examples, I haven't seen any widespread recognition of multiple hierarchies.
Most techniques/software tend to be designed for single hierarchies (e.g. outlines). This simplicity appeals to how the human brain processes information. It also only assumes a single context at a time which may be too simplistic and underpowered in many situations.
- catalogia 7y ago> There are 5 practical relationship roles in knowledge modeling: parent-child, associate, source-target. Parent-child is hierarchy. Associate is undirected peer. Source-target is less useful in general, but it roughly represents a directed peer relationship (e.g. A exports this good to B, and B exports that service to A -- there's a direction). I feel like this is missing something, namely in modelling relationships where a single child can have an arbitrary number of parents in a single context (or source-target without cycles.) I don't think that's adequately captured by multiple-hierarchies when you can't break the parents into discrete categories (e.g. mothers and fathers) and thereby into discrete hierarchies. If you try to model a DAG like that as multiple hierarchies by somehow imposing an order onto the set of parents, you'll get yourself into a quagmire.
- wenc 7y agoI'm not sure I follow completely but I'd like to explore this. To make things a bit more concrete, what is an example of what you're describing?
- catalogia 7y agoIn a version control system, a commit might have an arbitrary number of parents. Furthermore a single commit might have an arbitrary number of relationships to another commit (e.g. parents can also be grandparents, etc) Trying to reason about such a system as multiple-hierarchies will have you reasoning about a potentially huge number of hierarchies if the graph is well connected. I think it's more straight forward to reason about the system as a single graph, rather than a huge set of spanning trees.
- wenc 7y ago> I think it's more straight forward to reason about the system as a single graph, So I'm still not sure I totally get the objection -- please help me out here. In my mind, multiple hierarchies are represented by a single graph. When one reasons about the system, one will naturally only consider single hierarchies at a time for simplicity. The way to do this is center yourself on a node at a time, and then from that vantage point, traverse the node in different directions. In the system, each edge belongs to only 3 categories: P ("parent", directed), A ("associate", undirected), S ("source", directed). We're only considering hierarchies, so we'll restrict ourselves to "P". Each node can have an arbitrary number of relationships with other nodes. A family and work relationship could look like this. You -P-> your kid 1 You -P-> your kid 2 Mother -P-> You, Sister Father -P-> You, Sister Boss -P-> You Boss -P-> Colleague Company President -P-> Boss Company -P-> Company President Seems to me it should be easy to reason about multiple parents in different contexts -- they all belong in the same graph. Wikipedia sort of does this with its Categories box at the bottom of every page, but Wikipedia only has one kind of relationship category: P.
- dredmorbius 7y agoNetworked filesystems can approach multiple-hierarchy relations. Similarly for systems such as the WWW. Nonhierarchical associative structures tend to hit a complexity explosion threshold after a time (though arguably the same criticism might be made of hierarchical classifications) in which categories simply multiply.
- wenc 7y agoYes. For a WWW example, Wikipedia has multiple hierarchies, represented by multiple Categories at the bottom of every page (which in turn can belong to multiple Categories). This permits arbitrary level of hierarchy.
- dredmorbius 7y agoWikipedia also does have a nominal overall categorisation, FWIW: https://en.wikipedia.org/wiki/Wikipedia:Contents/Categories https://en.wikipedia.org/wiki/Wikipedia:Contents/Categories