sorry thought the diagram would infer the entities were associations. probably should have named them TerrestialPositiontoPostalAddressAssoc and TerrestialPositiontoContactMechAssoc. Yes they are new entities. they are a way to connect TerrestialPosition and ContactMech there would be no added ID's in TerrestialPosition or ContactMech TerrestialPositiontoPostalAddress.TerrestialPositionID TerrestialPositiontoPostalAddress.ContactMechID would link TerrestialPosition and ContactMech together. this removes the requirement to keep adding ID to TerrestialPosition and other entities to connect them. it gives a many to many, a one to many, or a many to one relationship.
Jacques Le Roux sent the following on 8/9/2008 10:31 AM: > BJ, > > Could you please use the convention for Entity and field like > Entity.field to describe your plan (like I corrected myself below) ? > It's hard to be sure of what you mean from your "diagram". > I guess you want to add 2 new entities TerrestialPositiontoPostalAddress > and TerrestialPositiontoContactMech. But I think we don't need them. We > have enough information in my proposition and should deal your concern > in code. > > Jacques > > From: "BJ Freeman" <[EMAIL PROTECTED]> >> to complete my thoughts >> TerrestialPositiontoPostalAddress >> TerrestialPosition ------------> TerrestialPositionID >> PostalAddressID <--PostalAddress >> >> and >> TerrestialPositiontoContactMech >> TerrestialPosition ------------> TerrestialPositionID >> ContactMechID <--ContactMech >> so if you have a contactMech with type Postal address you know to look >> for the TerrestialPositiontoPostalAddress to get the TerrestialPosition >> >> however if the type was anyother, you can just use >> TerrestialPositiontoContactMech >> >> >> >> BJ Freeman sent the following on 8/9/2008 2:59 AM: >>> ah, well I am working a plan to remove toname and attnname. >>> if you read the data books it was not laid out that way. >>> my concept was >>> contactMechtoPostalAddressAssoce >>> postal addresss -------------->postaladdressid >>> ContactMechID <------------contact Mech >>> the toname and attentent name would become part of the contact mech >>> types with those types using the same relationship. >>> so one postal address is in the database. >>> Just like in the real world that is just one address, or location. >>> >>> >>> >>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM: >>>> To answer you question you have only to have a look at the >>>> PostalAddress >>>> definition >>>> There are specific fields there like toName and attnName which can't >>>> shared. A PostalAddress is only an administrative mean to contact, not >>>> to locate >>>> >>>> Jacques >>>> >>>> From: "BJ Freeman" <[EMAIL PROTECTED]> >>>>> so when someone else puts in the same address will they point to the >>>>> same address or will a new record be added? >>>>> >>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM: >>>>>> ----- Original Message ----- From: "Jacques Le Roux" >>>>>> <[EMAIL PROTECTED]> >>>>>> To: <dev@ofbiz.apache.org> >>>>>> Sent: Friday, August 08, 2008 11:24 PM >>>>>> Subject: Re: Latitude, Longitude in PostalAdress >>>>>> >>>>>> >>>>>>> From: "BJ Freeman" <[EMAIL PROTECTED]> >>>>>>>> contact mech may not always be the same address and geopoint >>>>>>>> for an address it will always have the same geopoint >>>>>>>> 1) how do you connect an address that already exists with a New >>>>>>>> ConactMech. >>>>>>>> 2) how do you connect the assoicated Geopoint that goes with that >>>>>>>> address. >>>>>>> My last proposition should cover your previous demand. If you expire >>>>>>> an address then the geo-point this address used (point to) would >>>>>>> still >>>>>>> exist but as the address is obsolete we don't have to care (this >>>>>>> address and its associations should not be used anymore) >>>>>>> Let see your new questions now: >>>>>>> 1) Not sure to understand this one since an address is a type of >>>>>>> ContachMech. Did you not used a word for another ? >>>>>>> 2) PostalAddress.ContactMechId -> ContacMech -> >>>>>>> ContacMech.TerrestialPositionId -> TerrestialPosition >>>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech -> >>>>>> ContacMech.terrestialPositionId -> TerrestialPosition >>>>>> >>>>>> Jacques >>>>>> >>>>>>> Jacques >>>>>>> >>>>>>>> Jacques Le Roux sent the following on 8/8/2008 1:00 PM: >>>>>>>>> Yes , this is a good point to note. Actually the geo point >>>>>>>>> continues to >>>>>>>>> exist (it may be used by another thing) but the relation between >>>>>>>>> it and >>>>>>>>> the address does not. >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> From: "BJ Freeman" <[EMAIL PROTECTED]> >>>>>>>>>> but some means would need to link the terrestrial position to the >>>>>>>>>> address so if the address part is disabled, through the >>>>>>>>>> enddate, in >>>>>>>>>> the >>>>>>>>>> contact mech, so is the position associated with it. >>>>>>>>>> >>>>>>>>>> I agree on the rest. >>>>>>>>>> >>>>>>>>>> Adrian Crum sent the following on 8/7/2008 2:57 PM: >>>>>>>>>>> Jacques Le Roux wrote: >>>>>>>>>>>> Yes actually, I was just thinking about the >>>>>>>>>>>> EntityNameContactMech >>>>>>>>>>>> pattern, not a rule indeed. >>>>>>>>>>>> And because I wondered why we'd use this pattern in most other >>>>>>>>>>>> cases >>>>>>>>>>>> and not for GPS Geolocation, I just reviewed how Len Silverston >>>>>>>>>>>> suggests to deal with contact informations. >>>>>>>>>>>> At this stage I must admit that things were not much more >>>>>>>>>>>> clear. As >>>>>>>>>>>> far as I read Len speaks only about PartyContactMech and >>>>>>>>>>>> FacilityContactMech, but it's easy to extrapolate more >>>>>>>>>>>> usages as >>>>>>>>>>>> it's >>>>>>>>>>>> done in OFBiz. >>>>>>>>>>>> >>>>>>>>>>>> Now, please let me think loud. What is the difference between a >>>>>>>>>>>> postal >>>>>>>>>>>> address and a GPS point ? Is there more differences between >>>>>>>>>>>> them than between, say a telecom number and a postal address ? >>>>>>>>>>>> Obviously telecom numbers and a postal addresses have >>>>>>>>>>>> something in >>>>>>>>>>>> common that a GPS point does not share: they are mechanismes to >>>>>>>>>>>> contact somebody (or something at large). A GPS point is only a >>>>>>>>>>>> mean >>>>>>>>>>>> to locate somebody (or something at large), you can't contact a >>>>>>>>>>>> GPS point. So yes, it makes sense to differntiate a GPS >>>>>>>>>>>> point from >>>>>>>>>>>> other contact mech. A GPS point is not a contact mech as Len >>>>>>>>>>>> Silverstion defines one. It's a mean to locate not to >>>>>>>>>>>> contact. So >>>>>>>>>>>> now >>>>>>>>>>>> I better understant why you wanted things to point to it >>>>>>>>>>>> rather than having it point to other things. I still wonder >>>>>>>>>>>> though if >>>>>>>>>>>> we should not think a bit more about it. Putting a >>>>>>>>>>>> terrestrialPositionId in ContactMech does not make sense, as >>>>>>>>>>>> it's not >>>>>>>>>>>> a mean to contact but locate. Should we not introduce >>>>>>>>>>>> something else. Like a LocateMech, which could be maybe used >>>>>>>>>>>> for >>>>>>>>>>>> other >>>>>>>>>>>> stuff in future ? >>>>>>>>>>> I like the idea of making terrestrial position another >>>>>>>>>>> contact mech >>>>>>>>>>> type. >>>>>>>>>>> >>>>>>>>>>> I disagree that you can't contact a GPS point. You can if you >>>>>>>>>>> have >>>>>>>>>>> a GPS >>>>>>>>>>> device and a means of transportation - the same as a postal >>>>>>>>>>> address. How >>>>>>>>>>> is locating someone via car plus GPS device any different than >>>>>>>>>>> locating >>>>>>>>>>> someone via car plus a map? >>>>>>>>>>> >>>>>>>>>>> I can think of other uses for a terrestrial position contact >>>>>>>>>>> mech >>>>>>>>>>> type - >>>>>>>>>>> locating facilities or fixed assets like electrical transmission >>>>>>>>>>> towers, >>>>>>>>>>> cell towers, etc. They aren't going to have a postal address or >>>>>>>>>>> phone >>>>>>>>>>> number. If terrestrial position was another contact mech type, >>>>>>>>>>> then we >>>>>>>>>>> could use existing services, etc to associate that location >>>>>>>>>>> to the >>>>>>>>>>> facility. >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> > > > >
