Re: Attached Work plan

6 views
Skip to first unread message

Scott A Hatch

unread,
Mar 7, 2011, 3:03:22 PM3/7/11
to Grant Humphries, Annette Henry, Michelle Kappes, Moritz Schmid, Peter Kappes, seabi...@googlegroups.com

Hi Grant et al.,

My apologies...I've been vacationing in Arizona for a week and not checking email.  

It is a pleasure to see the fine planning document for seabirds.net which Grant has circulated.   This kind of systematic and professional approach will no doubt make all the differences as things move ahead.

I might emphasize here that the WOSPED (or 'Petrel', which I agree is more attractive) should be set up to serve as a true master list that can (and should) be used in various contexts, especially pertaining to world seabird databases.  Thus, for example, I'm revamping the design for the World Seabird Monitoring Database so that a 'World Seabird Personnel' table replaces two tables ('Contacts' and 'Observers') in an earlier schema (used for the Pacific Seabird Monitoring Database).  Each person in the master personnel table will receive a GUID when they are first registered.  People already in the PSMD database will be imported with their current GUIDs intact.  With respect to any given item of data, a person's role(s) in gathering/contributing the data will be identified by many-to-many relationships with another table of defined 'Roles'.  FYI, the table structure for the WSMD personnel table is as follows (all fields except the ID field, which is a GUID, are character data, with the number in parentheses indicating field length):

ContactID  (GUID)
ContactNo (9)
ContactRef (50)
ContactLastName (25)
ContactFirstName (20)
ContactMiddleInitial (5)
ContactAddress1 (100)
ContactAddress2 (100)
ContactAddress3 (100)
ContactCity (50)
ContactStateProvince (30)

ContactPostalCode (12)
ContactCountry (50)
ContactPhone (30)
ContactEmail (50)
RecordStatus (25)
EditComment (1000)

The last two fields are probably nonessential--they are used in the PSMD/WSMD and may or may not be appropriate for Petrel.  (By the way, if 'Petrel' does not yet stand for something, perhaps you could say it is short for Personnel tracker & e-list, or some such).  The table can be expanded or linked in any manner desired, but if it contains the fields described above, then I can link directly to it from the WSMD (as would any/all other databases).  Initially, it may be wise to keep the number of required fields to a minimum, maybe just ContactID (which is system-generated and assigned), first name, last name & email address (though even the latter will not be known in all cases, see below).

I used the term 'Contact' in the PSMD (as above), but I suggest that for purposes of seabirds.net, Petrel, and the world seabird databases, we start using a generic term such as 'Associate.'  Thus, people become seabirds.net 'Associates' and the field names above become AssociateID, AssociateNo, AssociateLastName, etc.  The table name might be "WorldSeabirdPersonnel" (or "WorldSeabirdAssociates").  I think it will be best to leave inclusion on the list wide-open, unless and until experience dictates otherwise.  As I say, professional roles (or absence of defined ones, as the case may be) can be spelled out in the larger schema (using a "Roles" table and linking tables), thus there should be no need to make the list exclusionary in any way.  In the case of the WSMD, there will be persons on the list who have been identified as having played some minor role in the generation of some quantity of seabird data at some time in the distant past.  They may or may not be still active in seabird work, and all we may have for them will be a name and minimal current contact information (or none at all), but they nevertheless will be given a GUID that will serve to identify them in perpetuity as contributors to the world seabird knowledge base.  (Also, it would be a useful strategy to try to contact every person so identified, with a suggestion/request that they visit seabirds.net and complete/update their personal profile).

So, this WSU-managed master list (relational database table) of seabird personnel (Petrel) will reside on the seabirds.net server and will be linked to as needed from all global seabird databases (i.e., wherever personnel accreditation and contact information is called for).

All the best,

Scott



From: Grant Humphries <humphri...@gmail.com>
To: Scott A Hatch <sha...@usgs.gov>, Michelle Kappes <michell...@yahoo.com>, Peter Kappes <olost...@gmail.com>, Moritz Schmid <moritz...@googlemail.com>, Annette Henry <Annett...@noaa.gov>
Date: 02/28/2011 03:51 PM
Subject: Attached Work plan





Hi everyone,

As per the discussion with Dave Irons a couple weeks ago, I've put together a draft work plan to present to the WSUTT for the next conference call.  
If I could ask you all to please look it over and make changes / edits where you can.  

Annette (and Moritz)  if you could pay particular attention to the work-schedule section it would be appreciated - you will both have a better idea of the time it will take to implement these things.  Please, if there is anything you disagree with in this draft, don't hesitate to speak your mind. 

Thanks everyone

Cheers
Grant[attachment "Workplan_March_GHDraft.doc" deleted by Scott A Hatch/BRD/USGS/DOI]

Grant Humphries

unread,
Mar 7, 2011, 5:22:42 PM3/7/11
to Scott A Hatch, Annette Henry, Michelle Kappes, Moritz Schmid, Peter Kappes, seabi...@googlegroups.com
Hey Scott,

Thanks for your reply.  To be honest, I hadn't really thought about it all like this: I.E. having the databases as relational to Petrel  (By the way, thanks for the acronym definition, I had been racking my brain trying to make something work - I had gotten as far as Personnel haha - now "Petrel" makes way more sense).  I don't know much about how databases will work online, but does anyone have any thoughts on how we could make those databases (WSMD, Pelagic Database, etc...) relational? I.E. Petrel will be "housed" on the website, but the other databases are being housed at Axiom <- is that type of linkage possible?

One point that you make, which I highly agree with, is about personnel accreditation.  Perhaps we could come up with a way of linking those databases to Petrel in such a way where, whenever someone's data is accessed and download, a counter is created for that person, or something like that (maybe a way of looking at who downloaded the data, and have some sort of "reporting" scheme where the user who downloads writes a quick summary (3 - 5 lines) of what they are doing with the data). 

Scott, could I post some of this email on the seabirds.net google forum? I think you make some good points that I would like to share with everyone.

Cheers
Grant

Scott A Hatch

unread,
Mar 7, 2011, 6:09:17 PM3/7/11
to Grant Humphries, Annette Henry, Michelle Kappes, Moritz Schmid, Peter Kappes, seabi...@googlegroups.com

Grant,

Yes, I think I did post the last message to seabi...@googlegroups.com but haven't confirmed that it "took".

For databases, I work in Microsoft Sequel Server, which is MS's industrial strength database software for use with (e.g.) web-based projects.  This can be distinguished from MS Access, for example, which is a desktop based system that, by and large, is not suitable for serving data via the Internet.  So I recommend that, ultimately, the seabirds.net website be supported by relational database software such as MS Sequel Server.  One issue is that this product can be fairly expensive (perhaps 5K or so).  There may be suitable open source (i.e., cheap or free) alternatives such as MySQL (which I think is what Axiom is using).  

Anyway, databases created in one of these software products (again, not counting MS Access), can easily communicate with each other in a distributed system.  Thus different databases residing on two or more servers (or on the same server, as the case may be) can be connected so that queries can read/write information (tables/records) from multiple sources at a single pass (all more or less transparent to the user).  This is why I say we should set up one central database on seabirds.net that will contain the one (unduplicated) set of tables of information that will be shared by multiple seabird databases.  Besides the personnel directory (1), these tables will include:  (2) document lists (citable literature associated with field data records), as well as pdfs of the documents themselves, (3) locations where seabird data have been collected, (4) seabird taxa (with Taxonomic Serial Nos.), (5) defined world ocean regions and political regions (for reference purposes), (6) data release codes, and possibly other tables.  These are all tables that will be common to all seabird databases (monitoring, colony register, pelagic surveys, diet studies, telemetry) and so it is desirable to have just one copy of this stuff in existence, which everyone will share.  I can help with the setup of this aspect of seabirds.net as we go along.

Best,

Scott



From: Grant Humphries <humphri...@gmail.com>
To: Scott A Hatch <sha...@usgs.gov>
Cc: Annette Henry <Annett...@noaa.gov>, Michelle Kappes <michell...@yahoo.com>, Moritz Schmid <moritz...@googlemail.com>, Peter Kappes <olost...@gmail.com>, seabi...@googlegroups.com
Date: 03/07/2011 01:22 PM
Subject: Re: Attached Work plan


Grant Humphries

unread,
Mar 7, 2011, 9:03:09 PM3/7/11
to Annette Henry, Scott A Hatch, Michelle Kappes, Moritz Schmid, Peter Kappes, seabi...@googlegroups.com
Hey Annette,

No problem - I will move those dates back. 

So how much has been paid for bluehost as of right now, (i.e. what do I put in the budget for this 12 month period?) And where did that money come from exactly?

Cheers
Grant :)

On Tue, Mar 8, 2011 at 2:18 PM, Annette Henry <Annett...@noaa.gov> wrote:
Dear All,

The workplan that Grant set forth is very nice - thank you. 

Two comments:
1) Appendix B: Budget: the renewal for BlueHost is $6.95/month as long as a 3-year subscription is renewed. Otherwise, the price is $7.95/month for a 2-year plans and $8.95/month for a 1-year plan (just want you to know this as I didn't know until I paid the first year subscription)
2) Appendix C: Work Schedule: 2.2 discussion forum by end of April; I am out of the office all of April and most of that time will be on a ship without email access; it would be great if this date were moved to May 15th.

Relationship databases are no problem as Scott spelled out. Axiom is using MySQL and it is likely the best and least expensive alternative. The Contact/Associate database can be modified anytime with minimal effort if needs change.

Thanks for all your hard work.
Love and kisses,
Annette

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
Annette Henry, PRD Survey Coordinator
Protected Resources Division, NOAA Fisheries
8604 La Jolla Shores Drive
La Jolla, CA 92037
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *





Reply all
Reply to author
Forward
0 new messages