Multi Value

This link describes MultiValue - it may be a bit of overkill though. And I am sorry that it is a PDF.

http://www.cdbma.org/presentations/nested_rdbms.pdf (BrokenLink 2006-09-26)

The paper is available ftp://ftp.software.ibm.com/software/data/u2/pubs/whitepapers/nested_rdbms.pdf (checked 2009-01-02)

See also NestedRelational

Since I would not attempt to describe MultiValue, because it is one of those Gnostic things - you need to experience it to appreciate it.

I could describe one of the benefits though.

MultiValue concepts, at least those manifest in Pick and the many Pick derivatives, transcend the usual distinction between process and data.

They permit the development of systems which directly model the solutions to the requirements at the source code level. Familiarity with MultiValue concepts allows the closest I have seen to ExecutableSpecifications. UML claims to lead at present, but it will never reach the clarity of MultiValue as long as it is constrained by underlying relational database concepts. And IMHO UML has lost the plot - it is becoming self-serving - the target of development improvement has been lost in the target of diagrammatic modelling tool improvement. -- PeterLynch

This paper interests me greatly since I have sort of stumbled toward NestedRelational as a universal data format in some of my own amateur hacking. It's very similar to ResourceDescriptionFramework in a lot of ways, although slightly simpler and more powerful, I think - you could base NestedRelational on pairs of (name,property) where (property) can be either a Boolean atom or a thing described by a set of properties, rather than triples of (subject,predicate,object) or (object,slot,value).

A simple Lispy syntax for such relations might be:

(name property property...)

(cat (name Fluffy) (owner Schroedinger) (in box) alive hungry (likes tuna salmon))

Our primary datastructure is therefore a named, one-column table, which can be nested indefinitely, unlike SQL tables which can only be nested one level deep (or two if you include the system data dictionary as a 'metatable' of table names).

Having created such a nested-table structure, we can then uniquely identify an attribute like 'cat name' as a path from the root which returns a table, or a path like 'cat likes tuna' as a path which answers a boolean yes/no query. This also seems very much like a string of ObjectOriented message-passes.

Unfortunately I'm not a professional logician or KnowledgeRepresentation? guru so I haven't yet worked out exactly what this sort of data model would imply, but it seems to me like it has the potential to be a very simple and powerful format midway between SQL, RDF and OOP.

A similar idea appears to be implied by some of ChrisDate's writings, though I'm confused as to whether or not Date thinks relation-valued attributes are acceptable or not. (I think he's saying they are, but perhaps hasn't quite fully realised that that's indeed what he's saying.)

I'm also intrigued by the idea of ExecutableDatabases?. It seems to me that if we have NestedRelational and can therefore let the value of any column be a table, we should be able to trivially extend this and let the value of any column be a *view* (computed from a query). If we do this, we may have a PureFunctional? TuringComplete data description language which could be used for DynamicProgramming. For instance, we could define a full GraphicalUserInterface built from TheHumbleDialogBox components, each being a NestedRelational 'view' or 'query' over a live dataset, which is itself composed of a series of views over views over views... going all the way back to the raw 'live' data sources, which could be files or ServiceOrientedArchitecture services.

This seems like it would be very similar to what some of the people working on FunctionalReactiveProgramming and FlowBasedProgramming are looking at, only integrated deeply into a relational DataModel.

If I could figure out how to develop this data model into an actual programming language I'd be very happy. (Some of the hangups at the moment include: does an empty property set indicate TRUE or FALSE? Are queries lists or sets? Could this be cleanly expressed as JavaScriptObjectNotation object graphs?) -- NateCull?

4 years ago NateCull? wrote this. I wonder how it is progressing. In relation to true/false value, i have found the most convenient to be null and zero and undefined as false, anything else as true. This allowed statements like -

     If (Record = ReadRecord?(File, Key)) then
           Process(Record)
     End

(cat (name Fluffy) (owner Schroedinger) (in box) alive hungry (likes tuna salmon))

 cat = AlterData?("Cats", "name",  "", "Fluffy", cat)
 cat = AlterData?("Cats", "owner", "", "Schroedinger", cat)
 cat = AlterData?("Cats", "location", "", "in box", cat)
 cat = AlterData?("Cats", "status", "", "alive,hungry", cat)
 cat = AlterData?("Cats", "likes", "", "tuna,salmon", cat)

or in a more MultiValue style

 AttributeNames? = BuildTuple?("name", "owner", "location", "status", "likes")
 AttributeValues? = BuildTuple?("Fluffy", "Schroedinger", "in box", "alive,hungry", "tuna,salmon")
 cat = AlterData?("Cats", AttributeNames?, "", AttributeValues?)

Nate's version is succinct.

CategoryDataStructure CategoryDatabase