 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / General DB Topics / DB Theory / April 2004c.d.theory glossary
Which words should be in it? Short posts for now, please. > Which words should be in it? > > Short posts for now, please. I have been building a set of definitions for materials I'm writing up, not all of which would be desirable on cdt, perhaps, but this is what I have at this point in alpha order: Glossary Items Aggregation Application Array Association Attribute Bag Boolean Class CODASYL Collection Column Constraints Data Source Database Declarative Dictionary Domain DynArray Entity Family Field File Function Graph Hierarchy Integrity Key List Map Matrix MultiValue Name Space Network Node Normalize NULL Object OO Persistence Predicate Procedural Proposition Query Record Record ID Referential Integrity Relation Row Schema Set Sub-value Table Tree Type Value Variable Vector View Web >>Which words should be in it? >> [quoted text clipped - 5 lines] > > Glossary Items [snip items] FreeCase died long ago, and if I learned one thing from that is don't be overly ambitious if you don't have the resources. The glossary was last updated in 1998. It is at http://www.xs4all.nl/~dannij/FreeCASE/glossary.html There is a lot of excellent explanations available on the web now, so for the c.d.glossary I would like to focus on the terms most problematic in the discussions *here*. I guess what I am asking is a kind of self-censorship: please mention just a few words which, if discussed in the glossary you think will help building common ground. <snip> > I guess what I am asking is a kind of self-censorship: please > mention just a few words which, if discussed in the glossary > you think will help building common ground. I figured you could check off the ones you thought most important. There might be some not on that list, but it is likely close to a superset of what you are looking for, right? Which of those do you think would help us agree on some common language in order to move forward from that point? --dawn >>I guess what I am asking is a kind of self-censorship: please >>mention just a few words which, if discussed in the glossary [quoted text clipped - 3 lines] > you are looking for, right? Which of those do you think would help us agree > on some common language in order to move forward from that point? --dawn I did some self-censoring preparation (1) for you :-) How about: > Class > [quoted text clipped - 19 lines] > > Type This service is now discontinued. > >>I guess what I am asking is a kind of self-censorship: please > >>mention just a few words which, if discussed in the glossary [quoted text clipped - 3 lines] > > you are looking for, right? Which of those do you think would help us agree > > on some common language in order to move forward from that oint? --dawn > I did some self-censoring preparation (1) for you :-) > [quoted text clipped - 24 lines] > > This service is now discontinued. Thanks and just put it on my tab. You can remove sub-value and perhaps add DBMS and maybe even RDBMS (since every time anyone uses that term someone has to up and state that there are no such tools available on the market today). --dawn I'll include a draft of a couple of these for starters. 1. Class 2. Database 3. DBMS 4. Domain 5. Function A binary mathematical relation with at most one b for each a in (a,b). A many-to-one relation of ordered pairs that maps each a to a unique b. It is important to note that every function is, by definition, a relation. 6. MultiValue (I'm sure this shoudl be trimmed since I wrote it for another purpose a while back) a) A data field (or attribute) defined to permit a variable number of values as a list (array). A field or attribute can be defined as single or multivalued. Data models that include multivalues are considered to be non-first normal form (sometimes NF2). The data may be viewed as logically flat tables for ODBC or SQL-92 queries, for example, by viewing each multivalued element as if in a logical child table. b) One name for the industry surrounding the Nelson-Pick data model platform. Flexible, non-first normal form software environment supporting a multi-billion dollar industry with users numbering in the multi-millions. Call it what you will -- the industry's best kept secret, a techno-cult, a legacy system, or a niche technology for PICK? zealots, mid-size companies, or old-timers -- developer productivity and bang for the buck solutions are not yet out of fashion. The family tree of MultiValue database vendors is extensive, with current products including those from IBM?, Raining Data?, Northgate Information Solutions, Via Systems, Revelation Software, and jBASE?. 7. Normalize 8. NULL 9. Object 10. Persistence 11. RDBMS 12. Relation 13. Type mAsterdam et al: `Formal Theory' should be included. The term `Formal Theory' will also REQUIRE: Set Relation Attribute Tuple Relational Model RDBMS Object (n): `Something intelligible or perceptible by the mind.' Because `Formal Theory' is included, we must EXCLUDE: XML XMLDBMS Object in any sense other than above OODBMS Respectfully, Timothy J. Bruce uniblab@hotmail.com </RANT> > `Formal Theory' should be included. > [quoted text clipped - 5 lines] > ... > Object in any sense other than above 'Object' is also used to mean (ISO): "model of an entity, characterised by behaviour and state.", with 'Entity' as "thing of interest". Would you object (heh) to that use? >'Object' is also used to mean (ISO): >"model of an entity, characterised by behaviour and state.", with >'Entity' as "thing of interest". The problem is that at least "model", "entity" , "behaviour", "thing" and "interest" are not formal concepts. Regards Alfredo > > `Formal Theory' should be included. > > [quoted text clipped - 11 lines] > > Would you object (heh) to that use? "Object" might be a term where we need multiple definitions, hoping that it will either be explicit or clear from context what a person is referring to. If someone is referring to coding constraints in an OO language, they might use Object as an instantiation of a Class or in whatever way the particular language uses that term. If an anti-OO person uses the term, there might be a sarcastic bent to it. In any case, "Object" will likely be the most difficult to define. We might get further faster by knocking off a few of the perhaps easier ones. I think terms like "Relation" have some more general agreement (although I could be wrong). At the very least, there are only a couple of differences that one would find in mathematics in the use of the term "Relation" (e.g. some might define it as a couple only, rather than tuple, because without loss of generalization mathematically it could be handled that way where in relational theory it needs to be a tuple). We might need two definitions of relation, however -- one for a mathematical relation (where "function" is a sub-class) and one that tosses all of the spices in for relational database theory. I suspect it wouldn't be hard to knock out "Type" either and state whether there is any difference between Type and Domain in our discussions. --dawn mAsterdam et al: > > `Formal Theory' should be included. > > The term `Formal Theory' will also REQUIRE: [quoted text clipped - 6 lines] > > Would you object (heh) to that use? No one, not even ISO has a *FORMAL* _theory_ or _definition_ of `object'. Since there is no *FORMAL* theory on `object' it would be irresponsible, misleading, and dangerous to the comp.database.THEORY group if we were to include any other sense of `object' than the philosophical sense, which is why I do invoke the intransitive verb sense in this post (HHOS). I do hate to remind you, who are doing us all a great favour by assuming the role lexicographer and making this keen glossery, that this is a THEORY group, and not an implementation group. The philosophical sense, by the way, is agreeable by all peoples, programmers and nonprogrammers alike, and adequately addresses the first O in OOP also. I'm serious here, Timothy J. Bruce uniblab@hotmail.com </RANT> > mAsterdam et al: >>>`Formal Theory' should be included. [quoted text clipped - 11 lines] > No one, not even ISO has a *FORMAL* _theory_ or _definition_ of > `object'. As long as there isn't, we are stuck with less than formal descriptions. I just don't like it that every time these words are used there is a big detailed discussion, and after many posts it appears there was a simple misunderstandig about the meaning of a word, and most of the discussion turns out to have been useless. > Since there is no *FORMAL* theory on `object' it would be > irresponsible, misleading, and dangerous to the comp.database.THEORY > group if we were to include any other sense of `object' than the > philosophical sense, which is why I do invoke the intransitive verb > sense in this post (HHOS). It would be all those things to require formality from all entries in the glossary. Even more so if you would only require it from an appearantly problematic term. > I do hate to remind you, who are doing us > all a great favour by assuming the role lexicographer and making this > keen glossery, that this is a THEORY group, and not an implementation > group. Ha! That was one of things I had some difficulty with. There is a lot of implementation specifics discussed in this group, and I don't mind *if* the main point is of a more general importance. For instance NULL, though an implementation thingy, should be in the glossary, but not how say DB2 implements it. > The philosophical sense, by the way, is agreeable by all peoples, > programmers and nonprogrammers alike, and adequately addresses the > first O in OOP also. ... but fails to reflect the meaning as it is used in most discussions here. > I'm serious here, Are you suggesting I am not? et al: > > I'm serious here, > Are you suggesting I am not? No, I merely suggested that some might think I was trying to be obtuse and contrarian simply for the sake of being contrarian. Hope your feelings aren't hurt, Timothy J. Bruce uniblab@hotmail.com </RANT> > No, I merely suggested that some might think I was trying to be obtuse and > contrarian simply for the sake of being contrarian. I did not have that impression. > Hope your feelings aren't hurt, Thank you, no - at least not by your posts :-/ What I'ld like to see, getting serious in a pleasurable way, is going to take a whole lot more than just a little glossary. Thank you for your concern. mAsterdam et al: > What I'ld like to see, getting serious in a pleasurable way, is going to > take a whole lot more than just a little glossary. What would be useful would be an actual, honest-to-goodness lexicon, which is no small task. If you would like to learn more about lexicography I can enlist the aid of a linguist, but I must again warn you the task exceeds even the Labours of Heracles. The problem of poor nomeclature is we computer scientists inherited poor nomenclature from the mathematicians. At one time English had the word (west saxon actually) `craftspr?ch'. English long ago abandoned this word, which was only recently replaced by `jargon'. Obviously English performed just fine for centuries while lacking such a word, but only by either using an entire sentance to paraphrase what once was a single word, or by overloading another word. It is this overloading which currently has us in trouble. What is an entity? Like the joke about geriatrics, the answer is `depends'. Entity in E/R diagramming means one thing, sort of. Entity in a UML event diagram means something completely different, sort of. We do not need a lexicon that lists all 57 flavours of `entity', but instead lists a different lexeme for each sense of `entity'. We require a one lexeme per concept ratio to be observed. English morphology uses a vowel shift to differentiate the verb and noun forms of the word `project', `record', `object', et cetera. Most English speakers are aware of this only tacitly, which is a great hinderance towards a unified vocabulary that overloads lexemes. The dificulties of overloaded and nebulous computing lexemes which may differ only in spoken form is magnifed further when translation becomes an issue. This subject is a massive volume in its own right, but is relevent here, and should be explored further. Suffice it to say the rules are different for Spanish, Persian, and German when it comes to loanwords. While English may seem to be the de facto standard for computing (when was the last time you conjugated a CommonDialog control?), and I do have dificulty even imagining a programming environment that was agglutinative for example, English may actually be a de jour standard, as evidenced by thriving practicioners in both Europe and Asia. This implies if we, as a community, do not standardize our craftspr?ch immediately the problems of confusion and misunderstanding will only grow worse. What does this have to do with the poor nomenclature above? I never hear doctors disagree on what a `rectal fistula' could possibly be. The following links should provide fruitful: http://www.dbdebunk.com/page/page/622923.htm http://www.dbdebunk.com/page/page/622916.htm http://www.dbdebunk.com/page/page/622867.htm http://www.esperanto.mv.ru/ESP/kframe.html > Thank you for your concern. It is we who owe ewe. Still hopeful, Timothy J. Bruce uniblab@hotmail.com </RANT> >mAsterdam et al: > >`Formal Theory' should be included. > Object (n): `Something intelligible or perceptible by the mind.' I don't see any formality here. I would exclude Object from the list. Regards Alfredo >>`Formal Theory' should be included. >> ... Object (n): `Something intelligible or perceptible by the mind.' > I don't see any formality here. I would exclude Object from the list. With 'list' are you referring to Timothy's 'Formal Theory' list or to the glossary? If the latter, why would an entry in the glossary require formality? >>>`Formal Theory' should be included. >>> ... Object (n): `Something intelligible or perceptible by the mind.' >> I don't see any formality here. I would exclude Object from the list. > >With 'list' are you referring to Timothy's 'Formal Theory' list Yes. > or to >the glossary? If the latter, why would an entry in the glossary require >formality? It would be very recomendable anyway. Regards Alfredo Alfredo, mAsterdam, et al: > >>>`Formal Theory' should be included. > >>> ... Object (n): `Something intelligible or perceptible by the mind.' [quoted text clipped - 5 lines] > >formality? > It would be very recomendable anyway. I included the philosophical sense in order to preclude any of the Simply Wrong senses that are available. If we had a C++ programmer, a Java programmer, a .Dot Net programmer, and a COM programmer we still would not have four people that could agree on `what is an object?'. The proposed sense is agreeable to all four, but is far from `formal'. Perhaps I was shooting at the moon, Timothy J. Bruce uniblab@hotmail.com </RANT> How about using some existing dictionaires as a base, or as linked references. There are FOLDOC, Wikipedia, and the Web Dictionary of Cybernetics and Systems, for starters. > How about using some existing dictionaires as a base, or as linked > references. There are FOLDOC, Wikipedia, and the Web Dictionary of > Cybernetics and Systems, for starters. I would like to keep focus on only those terms and explanations that help bridge the misunderstandings in this newsgroup. Specific links to serve that purpose are welcome. For example I searched FOLDOC for 'database' and 'class', and I don't think links to those explanations would help. BTW I *did* bookmark FOLDOC. > How about using some existing dictionaires as a base, or as linked > references. There are FOLDOC, Wikipedia, and the Web Dictionary of > Cybernetics and Systems, for starters. I'd advice http://www.wikipedia.org . You can enter your definitions there right now and link them up with all the other articles there. If necessary you can add a "namespace" so instead of [[tuple]] you could make an article for [[tuple (relational model)]] but that should be kept to a minimum. However, Wikipedia is not meant as a dictionary, which means that entries should have the potential of a full encyclopedia article. It's still ok to start them with just a definition, however, and I believe all the terms in your list would be acceptable. -- Jan Hidders How about this: ============== Preamble: This glossary aims to limit lengthy misunderstandings in comp.database.theory. People assume that words mean what they are accustomed to, and take for granted that the other posters have about the same connotations. They don't always. Some words are particularly suspect: database, class, normalisation. Some just cause minor annoyances, the misunderstanding is cleared and the discussion goes on: domain, type, transaction. We don't know well-accepted, formal or comprehensive definitions for everything. If you do have a useful reference, please provide it. If an informal description is all we have, so be it. The glossary is not meant as a dictionary or encyclopedia, such as FOLDOC, Wikipedia (http://www.wikipedia.org), and the Web Dictionary of Cybernetics and Systems. Specific links to serve the glossary's purpose are welcome, of course. ============== Note to native english speakers: please also check spelling and grammar mistaeks. :-) mAasterdam: > This glossary aims to limit lengthy misunderstandings in > comp.database.theory. Bravo! > People assume that words mean what they are accustomed to, > and take for granted that the other posters have about the > same connotations. They don't always. > Some words are particularly suspect: database, class, normalisation. > Some just cause minor annoyances, the misunderstanding is cleared and > the discussion goes on: domain, type, transaction. So we *will* have a unified vocabulary? > We don't know well-accepted, formal or comprehensive definitions > for everything. If you do have a useful reference, please provide it. So we *won't* have a unified vocabulary? > If an informal description is all we have, so be it. Will we have *any* kind of vocabulary? > The glossary is not meant as a dictionary or encyclopedia, ... So why even have it at all? Baffled by the goals, Timothy J. Bruce uniblab@hotmail.com </RANT> mAasterdam: I hoped my comments would have emboldened your efforts, rather than take the wind from your sails, so to speak. Many thanks for your efforts, Timothy J. Bruce uniblab@hotmail.com </RANT> > mAsterdam: > > I hoped my comments would have emboldened your efforts, rather than > take the wind from your sails, so to speak. I am not going to define the world. Hey - i had to look up 'emboldened'! (but it meant what I thought it would). Most discussion in this group is heavy brownsian movement right now. Many long and short vectors, and if one heats the closed barrel the intermolecular clashes have more impact - but the sum of it ..., no not NULL. Quantum leaps, database managementsystems which can do everything better then everything else, theories superior to all other, unified or even universal vocabularies. From relativity to 4VL, solving all philosophical issues in an instant. It looks like we can plan milestones by the million. Should I put in some nice quotes by Lakatos, von Bertalanffy, Barthes, Canetti and get away faking along with the 'discussion'? No. I could have responded to your questions with something like no no yes because it helps, but I don't think responding in that sense would really help. Specific suggestions would, BTW. For the glossary I prefer inch-pebbles. Wat??? Ik begrijp niet. Ik ken niet Lakatos, von Bertalanffy, Barthes, en Canetti. I wonder if I would understand your post better in Dutch. There are a lot of funky topics right now. However, there are grains of useful ideas in each of them, and the trick is to find those grains. When it comes to the glossary, I was simply pointing out that the problem is a bit deeper than many realize, because most of us are used to "winging it" instead of focused effort. The sad result is that the longer we go without order, the harder it becomes to establish order. I don't think my point was overkill, either. I mean, even if we sort out database terminology, if we don't sort out the rest, the non-database people will end up ruining our good work. It's a big task, but not an impossible one. Whether we will give it a good shot or not is another question. In any case, there's no need to set the insanity bit quite yet. --Senny >> mAsterdam: >> [quoted text clipped - 22 lines] > > For the glossary I prefer inch-pebbles. > Wat??? Ik begrijp niet. Ik ken niet Lakatos, von Bertalanffy, Barthes, > en Canetti. I wonder if I would understand your post better in Dutch. Nee. Ik denk 't niet. (I don't know if that is correct Dutch-- I'm third generation) I think its just a mood and we can help by jumpstarting the vocabulary effort again. It shouldn't be too hard to get a primary definition for relation, for example, even if we have to have some secondary versions too. I just re-read an early Codd paper and he really does start with a pretty standard mathematical definition of a relation. It gets expanded/altered/corrupted over time to get to where it seems to be today. So, if we start with what a typical relational theory definition would be and then have "mathematical relation" as a standard mathematical def, we might get on a roll. Given I'm not exactly a relational theorist, I'll yield the floor to someone with more of a clue. Maybe start a separate thread for each word we define, with subject "Glossary - Relation" for example -- just a thought. cheers! --dawn >>Wat??? Ik begrijp niet. Ik ken niet Lakatos, von Bertalanffy, Barthes, >>en Canetti. I wonder if I would understand your post better in Dutch. > > Nee. Ik denk 't niet. > (I don't know if that is correct Dutch-- I'm third generation) Heel goed! :-) > I think its just a mood Maybe mostly. I don't think so, but I can't very well look at my writings from the outside. One thing is not mood, but a message I am trying to get across. It concerns method. In order to get the glossary started with a chance of success, instead of (just) big individual statements we need a lot of small ones from many authors. (You already provided some.) > and we can help by jumpstarting the vocabulary > effort again. It shouldn't be too hard to get a primary definition for > relation, for example, even if we have to have some secondary versions too. Yep. But start, not, once again, not *jump* -start. It won't work (in this case). > I just re-read an early Codd paper and he really does start with a pretty > standard mathematical definition of a relation. It gets [quoted text clipped - 6 lines] > Maybe start a separate thread for each word we define, with subject > "Glossary - Relation" for example -- just a thought. Heh. That is exactly what I tried with "Class" and "proposed preamble". Tanpai! > Wat??? Ik begrijp niet. Ik ken niet Lakatos, von Bertalanffy, Barthes, > en Canetti. A search for any one of them in combination with say "proof", "system", "meaning" or "power" should provide you with some relevant, pleasant, and interesting reading. > I wonder if I would understand your post better in Dutch. Was my engrish (http://www.engrish.com) *that* bad? > There are a lot of funky topics right now. However, there are grains of > useful ideas in each of them, and the trick is to find those grains. Sure. As always. > When it comes to the glossary, I was simply pointing out that the problem is > a bit deeper than many realize, because most of us are used to "winging it" > instead of focused effort. The sad result is that the longer we go without > order, the harder it becomes to establish order. I don't think my point > was overkill, either. I very much appreciate your opening statement "c.d.theory lexicon overview" and I now wish I had stated that at an earlier point in time. Now we should aim for a better content/overview ratio. The content should be the result of a cooperative effort. As much as I appreciate Dawn's jumpstart list, it is now other peoples turn to provide some. > I mean, even if we sort out database terminology, if > we don't sort out the rest, the non-database people will end up ruining our > good work. It's a big task, but not an impossible one. Whether we will > give it a good shot or not is another question. > > In any case, there's no need to set the insanity bit quite yet. That would be a first try for the explanation of NULL? :-) >>For the glossary I prefer inch-pebbles. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.