Should we choose between topic-based & role-based paradigms

[iPlumb3r]

When we « arrive » at the tuple(s) concept(s) : #5 and beyond ... ... modeling paradigms are splitting in 2 mains categories :

• Those who considers only 2-ary oriented tuple (2 Ary non oriented tuple, could NOT carry a specific semantic others than « linked to » ;-) => e.g. RDF(S)-OWL, BORO Meta-Model, ...
• Those who considers as possible N-ary tuple (in this case « orientation » does not really make sense, than they must introduces concepts like Roles & Role Types => e.g. Topic Maps, Grakn, …

So, at this point, a very structured design choice should be done … (Not sure, it possible - or at least useful - to marry both approaches)

[ChrisGebhardt]

From the long-term architecture perspective, I actually don't think it's necessary to force this design choice. I try to be agnostic, to support future knowledge representation research. The two paradigms (and others) can co-exist in the 'Global Information Graph' (InfoCentral generalized data / info model) so long as they are contained within the same base data model -- one that guarantees immutability (via only hash refs), reliable referencing (via only hash refs), and deterministic serialization (to ensure consistent hashing). One of the most useful features of content-hash referenced data is that anything can be reified by default. Since the data is immutable relative to the hash, one only needs an (implicit) index value to specify elements (eg. statements) within the data entity.

Anything that can be expressed with n-ary tuples can be equivalently expressed in 2-ary, just inefficiently / rigidly. (reification or parametric patterns, see paper below) Nevertheless, it should be possible to write entailment rules between regimes. In engineering practice, however, I don't believe 2-ary will last forever, at least via the RDF data model. Consider the inelegance of even the best approach I've seen yet: Representing n-ary Relations in the Semantic Web. It still doesn't support extensible n-ary relations, which I consider a killer feature. These enable more collaborative vs. silo'ed information architecture and even support multi-versioning, multi-layering / branching, etc.