/Docs/S/About/Pitch/Support/Technical_v0.md
  Source views: Source JSON(ish) on GitHub (VSCode)   Doc views: Document (&k=5.r00t): Visual Print Technical: OpenParameters Xray
CommonAccord - JSON, XML, Graph
  1. The file data model of bare key=values can be transformed into JSON, XML, a graph database or whatever is efficient or compatible. We anticipate that JSON will be used for many exchanges, certainly those on blockchain. Graph databases may be used internally, especially for large PDSs.
  2. Graph query languages may also prove to be the most generalizable way of expressing relationships that are more than simply traversing the prefixed links from one list to another. For instance, while links currently support the idea of CEO.Spouse.Dog.Name, there is no way to get from the dog to the Dog's Spouse's CEO's company's name. That might look like --Dog.--Spouse.--CEO.Name, or perhaps something else. (Perhaps this introduces an element of instability, especially in a distributed system. One could say that this is a search function and should not be treated as content. E.g., if the Dog wants to claim a relationship to the dog's "owner" the dog should say so. If someone wants to attribute ownership of the dog to someone, they can do so, but that is part of the other person, not part of the dog.) Similarly, there is no syntax for, say, all of the shareholders of a company, or all of the kids in a class. Again, this could be a query, and again, perhaps any query that results in a "document" should be recorded as such - as a list of each shareholder or each kid, which is recorded as such.