Re: [TASS] Variable Star Database Tables/comments

[Chris Albertson <chrisja@jps.net>]

Looks good but of course I have some comments.  A few are nit-picks
but some of your proposed tables imply a policy that I think everyone
needs to consider we should probibly wait until everone who is likely
to care understands what by thier silence they are agreeing to.

1) How many "levels of canonization" do we need?  Michael G's design
   uses two.
2) Who can "promote" stars an how do we decide?

I would suggest three "levels" but the first level would be very weak.
Anyone would be allowed to "promote" stars to this level.  No review
would be required.  This will allow anyone on the Internet to "get their
name on a discovery".  The next two levels would require some review
by people we know and trust.

I assume that the person who first notices a star is variable will stay
interested in that star.  This is human nature.  We consider this somehow.

I like the idea of a "rejects" list.  I'd expand it to include rejects
for all levels.


Michael Gutzwiller wrote:
>
> As I promised in an earlier email I've created a first pass on database
> tables for TASS variable stars.  There are two IE diagrams attached, a
> logical and a physical model of the tables I'm proposing and how they fit in
> with the current schema.
>
> Each of the tables is explained below:
>
> TASS_cat:  This is an existing table.  It may be the TenXCat table instead.
>
> Person:  This is an existing table, or at least an existing script.  It is
> currently not on Michael's machine but the script exists and I propose not
> changing it, just populating it.  For the purposes of variable star analysis
> anyone who wanted to could add themselves to the table.
>
> KnownVariable:  This table has all the known variables, probably populated
> with the GCVS and possibly augmented from other sources.

Yes we should store a list of "Known Variables" someplace.  We should also
store lots of other "standard catalogs" on-line as well.  What about
a list of "known GRBs", or photometric standards such as Landolt's list.
The Tycho catalog and GSC, maybe even a list of bright asteroids and so on.
We should use a general method for handling all catalog data.  I propose
that we simply  import all of these lists as they were published but with
all latter corrections applied.

For every catalog we would have one table called "Catalogname_Xref_TASS_ID.
This would have two columns TASS_ID and CatalogName_ID.  A row exists
only where both IDs are resent.

>
> AnalystTeam:  A group of one or more Persons who are analyzing the TASS
> database for variable stars.  The name field is just an arbitrary name the
> group gives themselves.

We can make a generalization here and eliminate the "promoter: table.
We can add a few columns indicating "Permission".  "May Promote" could
be one.  Statistics could be fun to add too.  "Number candidates found"
and "reject ratio"  This also gives us the freedom to let either one
person or a team act as a Promoter.
>
> AnalystTeamPerson: Maintains the many to many relationship between the
> AnalystTeam and Person tables, this implies a person may be member of many
> teams and a team may have many persons.
>
> Candidate:  An entry in the TASS database chosen as interesting by the
> AnalystTeam.  It is just marked as interesting by whatever criteria the team
> choses.  Any team can mark any TASS_cat item as a candidate.
>
> RejectedCandidate:  This is an entry created by the analyst team to indicate
> misleading candidates.  These may represent contaminated stars which vary in
> brightness in RA or Dec due to a nearby bright star, etc.

These can be rejects from any list not just "candidates".
>
> Promoter:  A selected Person who can promote a candidate to a TASSVariable.

As I said above I think we can get rid of this table by defining a "Promoter"
to be an "AnalystTeam" with "May promote" set to true.
>
> TASSVariable:  An entry from the Candidate table that has been promoted to a
> full fledged Variable found by TASS.

I'll argue for three levels:
1) Candidate:    Someone, anyone, thinks the the star varies
2) Provisional:  Someone we trust checked it out.
3) TASSVariable: It stayed on the "Provisional" list without objection
                 and a second trusted person promoted it.
>
> Publication:  A publication that describes or mentions a particular
> TASSVariable.
>
> VariablePublication:  Maintains the many to many relationship between a
> TASSVariable and a Publication.  A variable may appear in many publications
> and a publication can contain many variables.

This table could become huge.  I think a publication is just like GCVS or any
other published list of stars.  We can treat it like a catalog.

>
> The following relationships can be enforced by the database:
>
> * The promoter of a variable may not be a member of the AnalystTeam.
> * A promoter can only be entered by Michael or some other trusted person.
> (This is our list of bishops.)
> * Many analyst teams may claim a single tass id but the system sets the date
> found value (via a trigger).
> * Only one TASS variable may exist for a single tass id.
>
> The three levels of candiates are:
>
> 1.  Candidate found by a team.
> 2.  Candidate promoted to TASS variable.
> 3.  Candidate published.
>
> Let me know of any comments or suggestions.
>
> Mike G.
>
>   --------------------------------------------------------------------------------
>                            Name: variable_logical.gif
>    variable_logical.gif    Type: GIF Image (image/gif)
>                        Encoding: base64
>
>                             Name: variable_physical.gif
>    variable_physical.gif    Type: GIF Image (image/gif)
>                         Encoding: base64

--
   --Chris Albertson             home: chrisja@jps.net
     Redondo Beach, California   work: calbertson@logicon.com