Re: [TASS] Variable Star Database Tables

[Alan McCallum <almac@ICONNECT.NET.AU>]

Hello Michael,
Apart from ER Tool Envy on my part, I think you have made a very good
starting "TASS variable business rules" document for discussion. I have a
few comments.

1) As the TASSCat table has not yet been cross-indexed to a KnownVar table,
I think we should populate the KnownVar table with a TASS_ID as the variable
analysis proceeds. As a particular star comes under close scrutiny, I think
we should also make the effort to cross-index to another catalog (the GSC)
at that time as well. The TASS identifier TASS/RA/Dec should make the object
unique, but it is still only relying on our own internal processes. A search
and cross-link to say, the GSC, is another useful validation step. This is
not meant to be _instead_ of a GSC <> TASS XLink, but just a temporary
measure.

2) I think the candidate table should have links to a light curve. Either as
a Tenxcat query, but probably better, as an analyst-supplied light curve.
This implies a LightCurve field. I think this comment also applies to the
dataset that defines the period. Anyone should be able to see most of the
steps in the publication process. Publication itself will set this data
permanently for archival purposes.

3) How will the "Bishop" (the promoter) know that a candidate has progressed
from being under investigation to ready for final checking/promotion? Of
course you could mean that simply "being there" means it is ready. Is that
what you mean? Another option is to provide a status field in the Candidate
table with a restricted set of values. Say N=new candidate but not looked at
further, U=under investigation by analyst team (which team?), R=ready for
checking by the promoter, P=promoter. or some such. Such a field should
really be restricted to teams and or team members.

4) Do we need a Spectrum field in the Candidate/TassVar tables in addition
to Type?

5) A very small point:
Under 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." A query
on the candidate table will bring up either the anlayst, or _all_ of the
teams that an analyst belongs to (Joined on AnalystID). Is that what you
meant? A team may be just one person, but a team is a team. Perhaps there
could be an AnalystTeamID field joined to the Candidate table. Small beer
really.
built in?

We really do need some basic rules to propose, promote and finally to
publish a candidate. For instance, promotion to the variable list is public
and well-checked out, (and is a useful cross check for other workers) but in
addition,  _publication_ should require an up-to-date search of, for
instance, our Japanese colleagues' lists.

And...is it time for TASS to create its first named committee? I jest....;>)

Alan.


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.
>
> 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.
>
> 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.
>
> Promoter:  A selected Person who can promote a candidate to a TASSVariable.
>
> TASSVariable:  An entry from the Candidate table that has been promoted to a
> full fledged Variable found by TASS.
>
> 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.
>
> 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.

--
Alan McCallum   (almac@iconnect.net.au)

Drumborg Victoria AUSTRALIA (38.0551S, 141.5868E)
http://orion.iconnect.net.au/~almac/index.html