Re: Order & meaning in a proposition

"Lemming" <thiswillbounce_at_bumblbee.demon.co.uk> wrote in message news:fg4670p1a2di7ht8ts5v571o7ca5c6dgkg_at_4ax.com...
> On Tue, 6 Apr 2004 14:55:46 -0500, "Dawn M. Wolthuis"
> <dwolt_at_tincat-group.com> wrote:
>
> >"Lemming" <thiswillbounce_at_bumblbee.demon.co.uk> wrote in message
> >news:1bu570ho991045ggi11t5fotv2klosm3ct_at_4ax.com...
<snip>
But that's not true at all. Sure, their relative ordering,
> importance, etc. are not modelled by the relationships between the
> tables, but if that information is pertinent, then it will be captured
> some other way -- for example by having a "seating_time" column on the
> table which links host to seating, or an "importance" column on the
> table representing the individual (or on the table representing the
> status of an individual in a particular context). Just because
> something isn't modelled by the relationships between tables doesn't
> mean it isn't modelled if it is considered important enough.

Bingo - I'm referring to stuff that no one would consider "important enough" from a data processing standpoint, but still provides information that need not be lost (in all cases). Why lose ordering if you don't have to?

> But I thought the point of this thread was to explore how a method
> could retain all the information from the statements used to derive
> the model, and not just those considered useful. From your original
> post which started the thread:
>
> "Once we split apart a proposition in such a way that we cannot get
> the original proposition back, even if we THINK we are getting the
> important aspects of it back, we have lost some of the meaning we
> intended to capture."
>
> and
>
> "A data modeling process that respects the integrity of the stored
> propositions so that they can be retrieved again has something going
> for it that the relational model lacks, it seems."
>
> Retaining information inherent in the statements from which the model
> is derived would seem to be "a good thing", and I'm keen to learn
> more. Obviously, retaining the original statements is a step towards
> it (and is what we should do anyway if we are doing our job properly)
> but your original post seems to hint that there is a better way.
>
> >while that would not be necessary (even
> >though possible) in an XML document.
>
> Is an XML document a data model? I've only seen XML used for
> presentation of data, not for data storage, so forgive my ignorance.

Nope, an XML document is not a data model, but modeling data for eventual deployment via an XML document (for example, for data exchange purposes) likely means use of a different data model in the first place. It is that different data model that is used by PICK systems, for example, and has been since the late 60's (pre-dating at least the publication of relational model information).

> >This isn't a great example, so I'll
> >try in the future to have a better one, but it should show that if we
don't
> >send back the propositions that we took in, in particular by keeping
> >compound subjects or nouns ordered together when that is how they are
> >presented, then we do remove some meaning and, in some cases, might even
add
> >some subtle meaning that wasn't there at all.
>
> I look forward to seeing and thinking about that example.
>
> >> Not being familiar with PICK (although I do remember hearing about it
> >> all those years ago) I have to ask how a PICK database is structured,
> >> and what advantages that structure has over a relational structure.
> >
> >From a data modeling perspective, you can think of PICK as XML documents
> >(but with exceptional performance). Cheers! --dawn
>
> Yes, but that's not what I asked. I asked what is the advantage of
> the structure of a PICK database over a that of a relational database?
> Given that I think of XML documents as glorified web pages, saying
> that PICK is just XML with go-faster stripes isn't really going to
> convince me to make the switch :)

There are pros and cons, as with any structure, but some of the advantages are:
1) Ease of maintenance. Any change in cardinality of an element (we used to store one color for the color of a car, but now we can store up to three, for example), can be done with very little effort.

2) Ease of Maintenance. Additionally, changes to the size of fields are changes only to the DESCRIPTION of a field (of which there can be many), possibly used by applications for input and output, but irrelevant to the database.

and many more examples of ease of maintenance related primarily to records looking much like the propositions/documents they are modeling and being easy to maintain in the very areas that propositions are likely to change, plus

3) Typically faster development times
4) Often (not always) easier queries for end-users -- notice how easy to get all of the varoius items with the Pizza in my pizza example -- the language for the query (which is currently used by about seven long-standing databases under different names) uses the extensible vocabulary, so heavy lifting is done more often in the "stored procedures" (not quite the same) for virtual fields than in the query language. End-users tend to love it (compared to SQL).
5) Rarely, if ever, is there a dedicated DBA function -- there is no need -- this is both due to the data model and the implementations 6) To some extent code is data and data is code; metadata is stored as data with the hub being a master dictionary holding the vocabularly for a name space. This vocabulary is also stored just like the data and the code.

and I'm sure I could run the question past the PICK community and come up with many other advantages, but I KNOW that I'll get as many comments related to the implementations (performance, etc) as the data model. I seem to recall a list somewhere on comp.databases.pick or the u2-users list at one point. --dawn

> Lemming
> --
> Curiosity *may* have killed Schrodinger's cat.
Received on Wed Apr 07 2004 - 01:18:19 CEST