 |
 | 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 / September 2005PIZZA time again :-)
Assume 1. there is a meaningful (or at least consequential) difference between: toppings([salami, mozarella, onions]). and toppings([mozarella, onions, salami]). 2. A, B, C are lists (conforming to the as yet to be published Spight LIST grammar in relational context). What should merge ([A,B], C). % merge list of lists into list mean ? I think it should merge A and B into C, preserving order, and fail if it can't. Or, if merge(+, +) just fail if C isn't a merge. (google for C3, Dylan, Perl) (clp - sorry for bothering you :-) > Assume > 1. there is a meaningful (or at least consequential) [quoted text clipped - 3 lines] > and > toppings([mozarella, onions, salami]). Of course there is. If you had the onions at the bottom, they would't cook right, although as a BOM for billing, there's no problem. Paul...  Signatureplinehan __at__ yahoo __dot__ __com__ XP Pro, SP 2, Oracle, 9.2.0.1.0 (Enterprise Ed.) Interbase 6.0.1.0; When asking database related questions, please give other posters some clues, like operating system, version of db being used and DDL. The exact text and/or number of error messages is useful (!= "it didn't work!"). Thanks. Furthermore, as a courtesy to those who spend time analysing and attempting to help, please do not top post. >>Assume >>1. there is a meaningful (or at least consequential) [quoted text clipped - 6 lines] > Of course there is. If you had the onions at the bottom, they would't > cook right, although as a BOM for billing, there's no problem. So, you agree assumption 1 has value. Good. Consider merge(ListOfLists, MergedList). Now merge ([[salami, mozarella, onions][mozarella, onions, salami]], M). should fail because salami is before mozarella in the first list, and after it in the second. It can't preserve the order. Should merge([[salami, buttonmushroom, mozarella, onions][salami, artichoke, mozarella]], M). succeed with M = [salami, buttonmushroom, artichoke, mozarella, onions] M = [salami, artichoke, buttonmushroom, mozarella, onions] or just the first one (because of the order of the lists)? > >>Assume > >>1. there is a meaningful (or at least consequential) [quoted text clipped - 30 lines] > > or just the first one (because of the order of the lists)? Which is the most truest answer me!!! This is a "Whois fairest of them all", sort of thing, but has useful application if you can limit the semantic expression of underlying features to something simple and comprehensible. The problem becomes when something more is read into the order than went into the ordering. It's important to put the onions on top so they cook but when you get into voodoo over who should get the cherry on top, its mebbe time to skip the cherry. Dhu Signature??????????????????????????????????????? Can't get good help? Contact Fubar the Hack: fubar AT neotext.ca Area code seven eight zero, Exchange four six six, Local zero one zero nine Highland terms, Canadian workmanship. All persons named herein are purely fictional victims of the Canidian Bagle Breeder's Association. Save the Bagle! Sun Ðhu ??????????????????????????????????????? >>>>Assume >>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 40 lines] > but when you get into voodoo over who should get the cherry on top, > its mebbe time to skip the cherry. In unix, the cherry on top is root. In CODASYL databases it's OOAK (One Of A Kind). In RM there is none. [] > In unix, the cherry on top is root. > In CODASYL databases it's OOAK (One Of A Kind). > In RM there is none. Ha. That's an answer worthy of whatever prize you get for a Turing test of sentience ;-) Dhu Signature??????????????????????????????????????? Can't get good help? Contact Fubar the Hack: fubar AT neotext.ca Area code seven eight zero, Exchange four six six, Local zero one zero nine Highland terms, Canadian workmanship. All persons named herein are purely fictional victims of the Canidian Bagle Breeder's Association. Save the Bagle! Sun Ðhu ??????????????????????????????????????? > >>Assume > >>1. there is a meaningful (or at least consequential) [quoted text clipped - 19 lines] > should fail because salami is before mozarella in the first list, > and after it in the second. It can't preserve the order. I don't know how you define a merge when there isn't an ordering defined on the type. Is there such a function? Your lists are ordered here, but your domain/type is not, unless you choose something like alpha order. I can imagine an interleave function that alternates ingredients from both lists and yields a pizza with salami on it twice (I think I'll pass on it, however). --dawn > Should > [quoted text clipped - 6 lines] > > or just the first one (because of the order of the lists)? >>>>Assume >>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 3 lines] >>>> and >>>> toppings([mozarella, onions, salami]). [snip] >>Consider >> [quoted text clipped - 12 lines] > but your domain/type is not, unless you choose something > like alpha order. That is another way of asking the same question. What should 'merge' do when the order is not in the values (as it would be if we took the ordering defined on the type) but just in their position, relative to other values. It is what I'm trying to find out. > I can imagine an interleave function that alternates ingredients from > both lists and yields a pizza with salami on it twice (I think I'll > pass on it, however). --dawn So that is not the desired behaviour. The resulting pizza will be richer than the originals, but I would like to see one you would like to eat. >>Should >> [quoted text clipped - 6 lines] >> >>or just the first one (because of the order of the lists)? [snip] >> I can imagine an interleave function that alternates ingredients from >> both lists and yields a pizza with salami on it twice (I think I'll >> pass on it, however). --dawn [snip] >>> Should >>> [quoted text clipped - 6 lines] >>> >>> or just the first one (because of the order of the lists)? I think merge([[salami, buttonmushroom, buttonmushroom, mozarella], [salami, mozarella, onions]], M). should succeed with: M = [salami, buttonmushroom, buttonmushroom, mozarella, onions]. > [snip] > >> I can imagine an interleave function that alternates ingredients from [quoted text clipped - 19 lines] > should succeed with: > M = [salami, buttonmushroom, buttonmushroom, mozarella, onions]. Sure. But why? A consistent rational needs to be included. Dhu Signature??????????????????????????????????????? Can't get good help? Contact Fubar the Hack: fubar AT neotext.ca Area code seven eight zero, Exchange four six six, Local zero one zero nine Highland terms, Canadian workmanship. All persons named herein are purely fictional victims of the Canidian Bagle Breeder's Association. Save the Bagle! Sun Ðhu ??????????????????????????????????????? >>I think >>merge([[salami, buttonmushroom, buttonmushroom, mozarella], [quoted text clipped - 4 lines] > > Sure. But why? A consistent rational needs to be included. It would be consistent with the heuristic 'don't modify input'. > >>I think > >>merge([[salami, buttonmushroom, buttonmushroom, mozarella], [quoted text clipped - 6 lines] > > It would be consistent with the heuristic 'don't modify input'. Ok, then this heuristic might still have bounding conditions that describe the points at which it breaks. eg, you reduce two salamis to one. if the second salami had come between mozarella and cheeze... the example above should mebbe have some more elements, anyways. Dhu Signature??????????????????????????????????????? Can't get good help? Contact Fubar the Hack: fubar AT neotext.ca Area code seven eight zero, Exchange four six six, Local zero one zero nine Highland terms, Canadian workmanship. All persons named herein are purely fictional victims of the Canidian Bagle Breeder's Association. Save the Bagle! Sun Ðhu ??????????????????????????????????????? >>>>I think >>>>merge([[salami, buttonmushroom, buttonmushroom, mozarella], [quoted text clipped - 11 lines] > to one. if the second salami had come between mozarella and cheeze... > the example above should mebbe have some more elements, anyways. I don't like my pizza's that rich. Anyway, along the same lines I think: merge([[salami, buttonmushroom, mozarella], [salami, mozarella, salami, mozarella]], M). should give M = [salami, buttonmushroom, mozarella, salami, mozarella] M = [salami, mozarella, salami, buttonmushroom, mozarella] or only the first one if the order /of/ (as opposed to /in/) the list matters (see other sub-thread). Another posibility is to disallow conflicting orders in the input (e.g. salami cannot be before and after mozarella in one list). > >>>>I think > >>>>merge([[salami, buttonmushroom, buttonmushroom, mozarella], [quoted text clipped - 27 lines] > Another posibility is to disallow conflicting orders in the input > (e.g. salami cannot be before and after mozarella in one list). So you'd apply a preordering function on the first list then, b4 the actual merge. Anyways, I'm not really sure what the best "merge" would be, because there are other imaginable conditions where you might want something else. But by providing these distinctions, you make a good case for using this merge as a local standard, or establish a notational convention for describing these distinctions. Dhu Signature??????????????????????????????????????? Can't get good help? Contact Fubar the Hack: fubar AT neotext.ca Area code seven eight zero, Exchange four six six, Local zero one zero nine Highland terms, Canadian workmanship. All persons named herein are purely fictional victims of the Canidian Bagle Breeder's Association. Save the Bagle! Sun Ðhu ??????????????????????????????????????? > >>>>Assume > >>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 27 lines] > their position, relative to other values. > It is what I'm trying to find out. Since 'merge' is commonly defined for lists with the same ordering, the function cannot be applied to lists with different orderings, e.g [a, b] and [b,a,c] (ordering is defined by an element position in the list) clearly cannot be merged. >>>>>>Assume >>>>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 34 lines] > b] and [b,a,c] (ordering is defined by an element position in the list) > clearly cannot be merged. That is the merge as used in some sorting algorithms, not a merge in it's own right. But if you feel more comfortable calling the discussed merge mymerge, truemerge, falsemerge or order_preserving_merge - ok. >>>>>>>Assume >>>>>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 39 lines] > merge mymerge, truemerge, falsemerge or > order_preserving_merge - ok. That is the merge function as used in functional languages like ML, Haskell or Lisp (not pure functional). My response relied on the common usage in those languages. Now, what is "a merge in its own right" ? Unless one defines 'merge_in_its_own_right', one cannot answer the question what 'merge_in_its_own_right' should do with lists where ordering is defined by an element position. [snip] >>>Since 'merge' is commonly defined for lists with the same ordering, the >>>function cannot be applied to lists with different orderings, e.g [a, [quoted text clipped - 14 lines] > 'merge_in_its_own_right' should do with lists where ordering is defined by > an element position. Let's see if we can come closer to a definition by listing desiderata: merge_in_its_own_right merges a list of lists into a list. It - should not have assumptions about an intrinsic order of the listed values. - should preserve the order of the values and fail if it can't. Should it also respect the order /of/ (as opposed to /in/) the lists? order_preserving_merge would, I guess - but there are two different orders, and assumption 1 (in the original post) only declares the order /in/ the lists to be of consequence. Also declaring the order /of/ the list of consequence makes order_preserving_merge(+, -) determististic. I suspect that is an advantage - but is it a good enough reason? I don't know. > [snip] >>>>Since 'merge' is commonly defined for lists with the same ordering, the [quoted text clipped - 24 lines] > - should preserve the order of the values > and fail if it can't. According to you specification the function should fail otherwise the function will behave as an ordinary (in the ML/Haskell sense) merge : 'if ordering(L1) == ordering(L2) merge otherwise fail' > Should it also respect the order /of/ (as opposed to /in/) the lists? Sorry, do not understand. > order_preserving_merge would, I guess - but there are two different > orders, and assumption 1 (in the original post) only declares the order > /in/ the lists to be of consequence. Also declaring the order /of/ the > list of consequence makes order_preserving_merge(+, -) determististic. > I suspect that is an advantage - but is it a good enough reason? Well, whether one cares about the resulting ordering or not is entirely up to a specific task at hand, or I am missing something ? E.g. if one does not care about ordering, one can just concatenate the lists and remove duplicates (emulating a union of two sets). Or just sort-merge using arbitrary (but the same) ordering. > I don't know. [snip] >>merge_in_its_own_right merges a list of lists into a list. It >> [quoted text clipped - 6 lines] > function will behave as an ordinary (in the ML/Haskell sense) merge : 'if > ordering(L1) == ordering(L2) merge otherwise fail' Yep. >>Should it also respect the order /of/ (as opposed to /in/) the lists? > > Sorry, do not understand. L1 = [a, c, d] L2 = [a, b, d] If the order /of/ the lists matters, the result is M = [a, c, b, d] If it doesn't, the result is M = [a, c, b, d] M = [a, b, c, d] >>order_preserving_merge would, I guess - but there are two different >>orders, and assumption 1 (in the original post) only declares the order [quoted text clipped - 10 lines] > >>I don't know. [snip] >>> merge_in_its_own_right merges a list of lists into a list. It >>> [quoted text clipped - 7 lines] > > Yep. On second thought I'm not sure. Does 'ordering(L1) == ordering(L2)' in the ML/Haskell sense hold for L1 = [a, b, a, c] L2 = [a, a, c] ? > [snip] > [quoted text clipped - 14 lines] > L2 = [a, a, c] > ? Since you define ordering by the position, then the ordering for L1 is: { (a,a), (a,b), (a,c), (b,a), (b,c)} ...which is not really ordering because of lacking antisymmetry ( (a,b), (b,a) ). So L1 is not ordered in the math sense regardless of the language. If L1 were [a,a,c,b] or [a,a,b,c], then it would be ordered. >> [snip] >> [quoted text clipped - 27 lines] > > If L1 were [a,a,c,b] or [a,a,b,c], then it would be ordered. Thank you. If it's possible to merge (in the _in_its_own_right sense :-) the lists anyway it means that the lists having some ordering is not a precondition. However, even if it is possible it may well be too difficult to start with. I'm actually trying to code something in prolog now. I am not used to that, but prolog feels like a good match for the problem (which was why I crossposted to clp - I hope you don't mind). > Well, whether one cares about the resulting ordering or not is entirely up > to a specific task at hand, ... Of course. > >>>>Assume > >>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 27 lines] > their position, relative to other values. > It is what I'm trying to find out. Perhaps it should do the same thing as a sort on a set where no ordering has been defined - ? > > I can imagine an interleave function that alternates ingredients from > > both lists and yields a pizza with salami on it twice (I think I'll [quoted text clipped - 4 lines] > originals, but I would like to see one you > would like to eat. I'd like plenty of mozarella, olives (black or green), tomatoes, and maybe even some pepperoni on either a whole wheat crust or a thin crust -- oh, and pineapple too. The ordering does make a difference, as does the city in which I'm eating the pizza -- in Chicago I'm OK with reversing the order and adding sausage to the pizza. I'm sitting in the biggest pork producing county in the U.S. right now and people order pizza with "swine" on it here. I talked students through a pizza example from the Head Frist Design Patterns book last year -- a fun book for anyone wanting to teach or learn OO design patterns. cheers! --dawn > >>Should > >> [quoted text clipped - 6 lines] > >> > >>or just the first one (because of the order of the lists)? >>>>>>Assume >>>>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 3 lines] >>>>>> and >>>>>> toppings([mozarella, onions, salami]). [snip] >>>>Consider >>>> [quoted text clipped - 22 lines] > Perhaps it should do the same thing as a sort on a set where no > ordering has been defined - ? Which would be - in the context of lists? Could you please (try to) translate what you mean onto the realm of lists? >>>I can imagine an interleave function that alternates ingredients from >>>both lists and yields a pizza with salami on it twice (I think I'll [quoted text clipped - 18 lines] > > cheers! --dawn You already know you are welcome to enjoy the best pizzas in Amsterdam whenever you feel like coming here :-) > >>>>>>Assume > >>>>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 34 lines] > > Which would be - in the context of lists? it seems like you are asking for sort ([[salami, mozarella, onions] intersect [mozarella, onions, salami]], M). sort based on what ordering? You could define the ordering to be whatever the first list has as the ordering unless that information is missing from the first in which case you need to use the second, enzovoort. But I'd say that it would be better to choose a word other than 'sort' for this new operation. > Could you please (try to) translate what you mean onto > the realm of lists? My point is that you cannot merge these two lists with the information provided because the ordering on these two lists does not define a unique ordering of the domain of the intersection (or union) of these lists. On the other hand, maybe someone has expanded the use of the term 'merge' and I'm just being ignorant. > >>>I can imagine an interleave function that alternates ingredients from > >>>both lists and yields a pizza with salami on it twice (I think I'll [quoted text clipped - 21 lines] > You already know you are welcome to enjoy the best pizzas > in Amsterdam whenever you feel like coming here :-) Careful -- you are bordering on flirtation there, and I'm from stoic Dutch roots. My people have populated some of the most conservative areas in the U.S. having left the Netherlands because of the immorality in cities such as Amsterdam. (Now they can only participate in such activities when making a pilgrimage back to the motherland.) >>>>>>>>Assume >>>>>>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 3 lines] >>>>>>>> and >>>>>>>> toppings([mozarella, onions, salami]). [snip merge] >>>Perhaps it should do the same thing as a sort on a set where no >>>ordering has been defined - ? [quoted text clipped - 10 lines] > enzovoort. But I'd say that it would be better to choose a word other > than 'sort' for this new operation. Any suggestions? >>Could you please (try to) translate what you mean onto >>the realm of lists? [quoted text clipped - 4 lines] > lists. On the other hand, maybe someone has expanded the use of the > term 'merge' and I'm just being ignorant. Heh - except for my abuse in this thread, not that I am aware of. Maybe merge is not such a good word for this either. To me it is, but I am not a native english speaker, I can't judge that. [snip] >>You already know you are welcome to enjoy the best pizzas >>in Amsterdam whenever you feel like coming here :-) [quoted text clipped - 4 lines] > in cities such as Amsterdam. (Now they can only participate in such > activities when making a pilgrimage back to the motherland.) The invitations stands. > I don't know how you define a merge when there isn't an ordering > defined on the type. Is there such a function? ... No function, because that would mean there would be a mapping to one result, no? I'm trying to put together some code, which hopefully demonstrates such a merge. It's in prolog. You can read it in clp. I'm not crossposting it to cdt. >Assume >1. there is a meaningful (or at least consequential) [quoted text clipped - 3 lines] > and > toppings([mozarella, onions, salami]). It can be yes or not, whatever you like >2. A, B, C are lists (conforming to the as yet to >be published Spight LIST grammar in relational context). [quoted text clipped - 7 lines] > >Or, if merge(+, +) just fail if C isn't a merge. It can be both, whatever you like A.L. >>Assume >>1. there is a meaningful (or at least consequential) [quoted text clipped - 5 lines] > > It can be yes or not, whatever you like Hm - you don't like your onions a little brownish? I do, and the assumption is clear, I think. If it is not, please ask. >>2. A, B, C are lists (conforming to the as yet to >>be published Spight LIST grammar in relational context). [quoted text clipped - 9 lines] > > It can be both, whatever you like ? What do you mean with 'both' in this case ? >>>Assume >>>1. there is a meaningful (or at least consequential) [quoted text clipped - 9 lines] >I do, and the assumption is clear, I think. >If it is not, please ask. I don't like pizza. >>>2. A, B, C are lists (conforming to the as yet to >>>be published Spight LIST grammar in relational context). [quoted text clipped - 11 lines] > >? What do you mean with 'both' in this case ? Whatever you like more. A.L. >>>>Assume >>>>1. there is a meaningful (or at least consequential) [quoted text clipped - 11 lines] > > I don't like pizza. You might be able to transpose the problem to some topic you do have some affection with. If you lack that capacity don't bother. >>>>2. A, B, C are lists (conforming to the as yet to >>>>be published Spight LIST grammar in relational context). [quoted text clipped - 13 lines] > > Whatever you like more. What is your point? >> Whatever you like more. > >What is your point? My point is that there are no universal, worl accepted standards how to answer the questions you are asking. Therefore, the answer: this is up to you. A.L. >>>Whatever you like more. >> [quoted text clipped - 3 lines] > to answer the questions you are asking. Therefore, the answer: this > is up to you. I see. Well, I'm not sure what I like more yet. When I read http://www.python.org/2.3/mro.html I found that the merge of linearizations Michele Simionato uses, where closer to my intuition of 'merge', than what I ever read anywhere else (except that it takes two lists instead of an arbitrary number). Maybe you are right. In that case it is just a pragmatic, contextual choice. > Assume > 1. there is a meaningful (or at least consequential) [quoted text clipped - 19 lines] > > (clp - sorry for bothering you :-) Off topic: I have always assumed that the toppings on a pizza form an (unordered) set, that > toppings([salami, mozarella, onions]). > and > toppings([mozarella, onions, salami]). will use exactly the same ingredients, prepare and cook exactly the same way, cost exactly as much, and taste exactly the same. I would be VERY surprised if Domino's had a different opinion. And that brings me back to the topic: You can ALWAYS represent a set as if it were a list, by simply presenting the elements in an arbitrary order. You can ALWAYS represent a list as if it were a set, by including an attribute that marks each element's position in the list. The question is not WHETHER the above can be done. The question is WHEN it SHOULD be done. > You can ALWAYS represent a set as if it were a list, by simply presenting > the elements in an arbitrary order. You can ALWAYS represent a list as if [quoted text clipped - 3 lines] > The question is not WHETHER the above can be done. The question is WHEN it > SHOULD be done. The question the above rasises for me is: If we can ALWAYS do either of the above, then why can't this just be considered a view on the data? In other words, why can't we pick which view we want when we want it? Marshall > > You can ALWAYS represent a set as if it were a list, by simply presenting > > the elements in an arbitrary order. You can ALWAYS represent a list as if [quoted text clipped - 9 lines] > just be considered a view on the data? In other words, why > can't we pick which view we want when we want it? I think it can. I think the argument over lists versus sets is really the argument about location based retrieval versus content based retrieval. It's just in a different guise. David Cressey wrote: >>Assume >>1. there is a meaningful (or at least consequential) [quoted text clipped - 30 lines] > way, cost exactly as much, and taste exactly the same. I would be VERY > surprised if Domino's had a different opinion. Asuuming they don't, I wonder if this was a deliberate decision to keep things simple. > And that brings me back to the topic: > > You can ALWAYS represent a set as if it were a list, by simply presenting > the elements in an arbitrary order. You can ALWAYS represent a list as if > it were a set, by including an attribute that marks each element's position > in the list. How are you going to do that in our hypothetical PIZZA ordering system? It is, I suspect, a non-trivial excersize if we want the user not to notice the implementation. > The question is not WHETHER the above can be done. The question is WHEN it > SHOULD be done. And WHY - and if it can be prevented. > David Cressey wrote: > > Off topic: I have always assumed that the toppings on a pizza form an > > (unordered) set, that [quoted text clipped - 9 lines] > Asuuming they don't, I wonder if this was a deliberate > decision to keep things simple. The toppings on a pizza are a set, rather than a list. http://www.dominos.com/Public-EN/Site+Content/Primary/See+the+Menu/Pizzas/ I rest my case. [snip] >The toppings on a pizza are a set, rather than a list. > >http://www.dominos.com/Public-EN/Site+Content/Primary/See+the+Menu/Pizzas/ > >I rest my case. If I order potato, I want it on top of the cheese. That is not a set. Sincerely, Gene Wirchenko > If I order potato, I want it on top of the cheese. That is not a > set. Ah! If it has an order, and it doesn't allow duplicates, then it's an ordered set, which is not a list, nor a (regular, unordered) set. Marshall > > If I order potato, I want it on top of the cheese. That is not a > > set. > > Ah! If it has an order, and it doesn't allow duplicates, then it's > an ordered set, which is not a list, nor a (regular, unordered) set. double cheese, please --dawn > Marshall > > > If I order potato, I want it on top of the cheese. That is not a > > > set. [quoted text clipped - 3 lines] > > double cheese, please --dawn Double cheese could either be its own topping, or "double" could be a modifier to a topping. You still have an ordered set. Although for the purposes of data modelling, I don't see that the order is relevant. The fact that the person who makes the pizza puts the toppings on in a certain order doesn't mean that order is relevant to how you specify a pizza. I've never heard anyone ordering pizza say anything like "please put the pepperoni down first, then the cheese." It's just "pepperoni and cheese" and its up to the person making the pizza to use the correct order. Marshall "Marshall Spight" <marshall.spight@gmail.com> wrote: > Although for the purposes of data modelling, I don't see > that the order is relevant. The fact that the person who [quoted text clipped - 5 lines] > its up to the person making the pizza to use the correct > order. I've already rested my case, so I'm not about to reenter the argument. But, since you're the "semantics guy" in this forum, I can't resist bringing up the question of semantics, implicit in the topic starter: Here it is, all the way back to the beginning of the topic. > Assume > 1. there is a meaningful (or at least consequential) [quoted text clipped - 3 lines] > and > toppings([mozarella, onions, salami]). That word "meaningful" should be a clue that, ultimately, what we're discussing here is semantics. The first question is, "meaningful in what context?" In terms of databases, there are at least two contexts: the context of the transaction that wrote the data, and the context of any transaction that reads the data. So the question is not "meaningful in use" but "meaningful in exchange". The "obvious exchange" to me is the case where someone orders a Pizza from a delivery store (I just happened to use Domino's as an example), and orders a set of toppings. A while later, the delivery man shows up, the customer looks in the box, and says "this isn't what I ordered". The delivery man looks in the box, looks at the order, and says "yes, it is." The customer grabs the order out of the delivery man's hand and looks at it and it says, > toppings([mozarella, onions, salami]). whereupon the customer says, "what I actually ordered was, > toppings([salami, mozarella, onions])." And the delivery man says, "well, it's the same thing.". Now, I don't care whether the cook always adds the ingredients in a set order or not. All I care about are the context of the order and the context of the delivery. So, to make a long story short, the question of "is it a list or a set"? boils down to "what are you going to do with the data"? This question is relevant to data modeling as well as to process modeling. > Marshall David Cressey wrote: > Marshall Spight wrote: > [quoted text clipped - 25 lines] > That word "meaningful" should be a clue that, ultimately, what we're > discussing here is semantics. Yes. And even earlier: The word "assume" aks the reader to take what is assumed as given, so we can get to the question at hand. A lot op the postings just go into wether the difference in the example could actually be meaningful. What is bothering some people about the assumption is of course (rephrased from Marshall Spight's statement that it isn't in this case): "For the purposes of data modelling, order can be relevant." IMO below you make a strong case that it can. > The first question is, "meaningful in what context?" > In terms of databases, there are at least two contexts: the context of the [quoted text clipped - 26 lines] > boils down to "what are you going to do with the data"? > This question is relevant to data modeling as well as to process modeling. > "Marshall Spight" <marshall.spight@gmail.com> wrote: > [quoted text clipped - 3 lines] > reads the data. So the question is not "meaningful in use" but "meaningful > in exchange". Yes. Part of the problem with this thread is that we're partly examining issues of the semantics of order, and we're partly modelling a domain that (I don't expect) any of us are familiar with, other than in the role of "eater." > whereupon the customer says, "what I actually ordered was, > > toppings([salami, mozarella, onions])." > > And the delivery man says, "well, it's the same thing.". While certainly possible, this doesn't sound like a particularly real-world example to me. But this is comp.databases.theory, and not comp.databases.pizza, so perhaps I should confine my remarks to the first of those two domains. :-) > Now, I don't care whether the cook always adds the ingredients in a set > order or not. All I care about are the context of the order and the context [quoted text clipped - 3 lines] > boils down to "what are you going to do with the data"? > This question is relevant to data modeling as well as to process modeling. Agreed. If, for a given application, we need to capture not only the elements of a collection, but also an order for them, then we have a list. If order is not required, then we have a set. Also, it is possible to model a list with a set, assuming you conform to certain constraints (index attribute starts at 0 and is consecutive) and vice versa, (ignore the list index and don't repeat list members.) Marshall |
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.