[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Research"
I've been thinking about the general problem of catalog
cross references. I think this is the way to solve this
problem in a ganeral way. Certainly we can NOT create a column
in the database and then give anyone who wants the ability to
write into that column. OK we could but what a mess and what if
no one can agree what to write there. No, I think a better
way is with a catalog cross reference.
For example I like to classify stars by their likelyhood of
being the home planet of space alians. For reasons unknown
to me not many people follow my work closely. None the less
I look at TASS data for morse code messages hidden in the
variability. (eclisping binaries tend to send the letter
"e" over and over) and I want to store the text strings these
stars are sending in the TASS database. I ask but the database
keeper seems uninterrested in adding a "message text" column
So what do I do? Ah, I make a new catalog called "MorseMessages"
with two colums as folows:
# MM_Number Message
1 E
2 E
~
2238432 E
2238433 Howdy Earthings
All catalogs look something like the above. There is a unique
name or ID asigned to the row and then there is some data following
the ID. In my case I asign the ID using a counter. The HST Guide
star catalog, Tycho and all the others have their own system.
TASS will have it's own system too.
Next I build a two column "Cross ID Table" that relates my "MM_Number"
the the ID field in the TASS database. Notice that this is completely
general and allows for an m:n relationship. My objects and TASS
objects are not constrained to by one to one. This allows for
the common problem of blends, one catalog resolving doubles
that are unresolved in another.
Given that we are using SQL I can write a single statement querry
that pulls data from both MorseMessage and the TASS photometric
observations and presents the result in a combined table. This
is just a three-way join. Logically, but not physically my Morse
Code Messages ARE in the TASS database but notice there is no
change to existing TASS tables, no extra work for the maintainer
of those table. And no software broken due to the change.
"standard" catalogs cross referenced to TASS data would be very
usfull. There are enough of these catalogs that some general
purpose , generic method is need to perform the cross ID.
Once you have this you also have the means to allow each "researcher"
to have and maintain his own catalog for his own purposes without
having to worry about one researcher stomping on another's toes
while at the same time everyone getting to share data without
the need for making private copies.
Now if you have done the above you use the same mechanium to
check if a TASS star is already in a catalog of variable
stars as to see if I think that star is saying "Howdy Earthings"
Or if some other guy thinks it is an "RA Vir or some such"
It's not much of a stretch to imagine another table that
catalogs web pages. The cros ID table would relate URLs to
TASS-ID. Again this is an m:n realationship. A web page
could talk about an entire class of TASS stars or you could
have 10 URLs for one star.
Databases are pretty good about keeping track of who owns
what data and who can read or write which tables. Keeping
this all straight is not hard to handle.
--- Tom Droege <tdroege2@earthlink.net> wrote:
> Mike,
>
> OK here is what I think he wants. If someone looks at the data for a
>
> particular star and discovers it is RA Vir or some such, then it
> would be
> nice if he could tell the data base. Also it might be nice if John
> can put
> an entry in the data base that says this star is an EA and not worth
> looking at further or some such. Possibly there should be room for
> extendable comments. Every one that looks might want to add a
> comment. See ApJ 288 345-348 or some such comment. Just my 2 cents
> not
> knowing anything.
>
> Of course even nicer would be for the data base to look at all the
> stars in
> the GCVS and tag the entries that are GCVS stars. Since the
> positions of
> the GCVS may vary from our positions, then you need an entry that
> says
> something like "this star is near WG Sc and migh be it" Our
> positions are
> probably better than many of the listed positions of the known
> variables. Something that read through our data and compared it to
> the
> GCVS might do a great service by updating the positions of stars in
> the
> GCVS. On the other hand this might be a very presumptions thing for
> me to
> say, but I have just been reading the comments by experts who say
> this or
> that variable is out of position.
>
> Tom
>
>
>
> At 08:05 PM 6/5/03 -0500, you wrote:
> >Guys,
> >
> >John, I'm not getting what you are asking for.
> >Could you give me a specific example?
> >And also any thoughts on how I could best present the information to
> make
> >it easier for you.
> >
> >Thanks and sorry for being so dense tonight,
> >
> >Mike
> >
> >Tom Droege wrote:
> >>Mike,
> >>Some research.
> >>Tom
> >> From JG
> >>Hmmm, somehow previously mentioned objects are going to have to be
> >>flagged or put in a discrete table or something just so people
> don't
> >>keep rediscovering original stuff, although if no one has looked at
> >>it despite it being known, that is not a bad thing. I know they
> >>usually end up on a web page, but as more are found, that in itself
> >>is tedious to double check, when compared to a lookup table /
> >>variability flag (if in the database). Of course, somebody has to
> do
> >>it. Always the problem ;)
> >>
> >>
> >
>
>
>
=====
Chris Albertson
Home: 310-376-1029 chrisalbertson90278@yahoo.com
Cell: 310-990-7550
Office: 310-336-5189 Christopher.J.Albertson@aero.org
KG6OMK
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com