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...)
eg
(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