electronic tagging data base

[Christopher Jones]

Hi John,

I was just able to catch up on this conversation thread, and thought 
that I'd chip in since Matt hadn't been able to respond back yet.  He 
can clarify things as well.  I work for PISCO, and have discussed using 
this system for a shared tracking database during a workshop at UC 
Santa Cruz, but at the time, people at the meeting were leaning towards 
a Microsoft Access type database.  Also, morpho was in an even earlier 
development stage at that point.  I'll comment where I can inline.
On Feb 9, 2004, at 8:01 AM, John Sibert wrote:

> 1. I find the notion of "profile" a bit confusing. It seems more 
> applicable to the web site than to the creation of a data base on a 
> local computer.
I found it particularly useful when I had multiple roles to fill.  For 
instance, I use one profile to manage data in my PISCO role, so my 
profile logs me in as uid=cjones,o=PISCO,dc=ecoinformatics,dc=org. 
(This is my unique identifier in the distributed LDAP authentication 
database).  Next, since I collaborate with folks at the Santa Barbara 
Coastal LTER, I use another profile that logs me on as 
uid=cjones1,o=LTER,dc=ecoinformatics,dc=org.  What is very powerful 
about this system is that I can share datasets that I create as my 
PISCO profile with people outside of that user community.

> 2. The location of the Morpho files in a W32 system is not where I 
> would have placed them and I could find no way to modify the default 
> directory.
Setting this directory in the Preferences dialog seems like a good 
idea.  Developers struggled with how accessible this directory should 
be, because it essential stores the internal Morpho files, and any 
manual changes to them from outside of Morpho could potentially make 
them unreadable by morpho.  The reason for this is mostly due to the 
strong version control in Morpho (and the Metacat database).

> 3. The type face used in the field descriptions within Morpho is too 
> small for old eyes such as mine.
Noted.

> 3. I like the "tree" display of the metadata structure.
Noted.  This is constantly debated, and new ways of presenting the 
metadata are also being developed.  If you understand XML, the tree can 
be easy to navigate.  If you understand EML, it's even easier.  If your 
metadata management experience largely stems from using tables (ie 
RDBMS), than it can be a stretch.  It's hard to balance the UI needs of 
everyone.

> 4. The use of east and west longitude is awkward for those of us who 
> operate near the dateline and who track fish that cross it regularly. 
> We generally use east longitude for the whole domain, ie. positive 
> longitude from 0 to 360 so that west longitude extends from 180 to 360 
> (instead of -180 to 0). Good public domain mapping software, such as 
> GMT, easily accommodate this convention.
Ah, that's an interesting issue.  During the development of EML, the 
GeographicCoverage section largely reflected what was in the USGS's 
geospatial standard (CSDGM FGDC-STD-001-1998).  The Spatial Domain 
section (1.5) defined the range of each bounding coordinate to be:
Domain:  -90.0 <= North Bounding Coordinate <= 90.0
Domain:  -90.0 <= South Bounding Coordinate <= 90.0
Domain:  -180.0 <= East Bounding Coordinate <= 180.0
Domain:  -180.0 <= West Bounding Coordinate < 180.0

And so, that's where the convention came from.  So, it seems that tools 
like Morpho should 'present' the interface based on a preference, and 
do the conversion, as you had mentioned in software like GMT.

> 5. Need to be able to copy and paste into Morpho fields.
Noted.  Depending on the version of Morpho that you are using, this may 
already have been addressed.
> 6. Some of the field documentation is ambiguous, eg. what does 
> publication place mean? A city or a journal?
Yes, documentation is a tough one.  The tooltip popups in Morpho are 
not hard-coded into the application.  Rather, they are parsed from the 
documentation fields that are embedded into the EML schema documents.  
We've struggled with the 'audience' for the documentation.  Some of the 
documentation needs to target developers, whereas other field 
documentation needs to target different user communities.  For 
instance, people that frequently use GIS are accustomed to the the 
concepts of 'entities' and 'attributes', whereas other folks may only 
be familiar with 'tables' and 'columns'.
So, the documentation largely relies on EML - but there's nothing to 
say that you couldn't modify the EML schema prior to compiling Morpho, 
such that the documentation more closely targeted your user community.
So you know, the KNB has faculty, graduate students, and postdocs 
involved in formally testing the KNB software.  There's been a bunch of 
feedback on documentation, and in particular, there has been an effort 
to refine the help system within Morpho for the ecology community.
Okay - well - this is a long subject, but to answer your question - 
publication place is the city in which the article, book, etc. was 
published.

> 7. Some of the documentation is a bit jargon heavy. It took me some 
> time to figure out that a resource is the data base. (I have had some 
> experience building GUIs, and one lesson that I learned is that the 
> developer of the software should not write the documentation.)
Yep. Point well taken.  We need people to take part in this that lean 
to the domain science side rather than the technology side.
>
> A couple of specific questions:
> 1. Can you please tell me how to control access to a specific user or 
> a group of users?
If this is Morpho 1.4, access control is linked in at the 'top' level 
of the dataset, so you need to open the data package, and in the 
summary box at the top (with the author, title, etc.) click on the 
'more' link.  this opens up the general info panel more, and at the 
bottom there is a link that says "something.x.x provides access control 
rules for something.x.x".  Click on the first link to view the access 
control rules. Once you are viewing them, click on the 'edit' button to 
edit them in the tree editor.

FYI, much of this clunkiness is changing in the Morpho 1.5 release, 
since it now has support for EML2.0.0.  There has been major 
improvement to the interface.  The status of this is tracked in the bug 
database at:

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=88

> 2. Must the data be hosted at KNB web site or could host the data at 
> the PFRP web site?
You can definitely host the data locally by installing and maintaining 
your own Metacat database.  At PISCO, we run two metacats, and plan to 
replicate data between them using the built-in replication feature of 
Metacat.  When our system is stable, we also plan to replicate to the 
central KNB servers so that our metadata are viewable to a wider 
community.  Still, all access control is respected across catalogs, so 
the KNB metacats will only allow users to view data and metadata that 
are authorized.

> 3. In our tracking applications, many data fields would be similar and 
> would be repeated many times. For example, a track consists of date, 
> longitude and latitude. Or the raw data from one model of electronic 
> tag is always comprised the same fields. Is there a way to copy 
> meta-data from file to file?
Yes.  In the tree editor, you can copy a whole section of a tree (with 
the children), and paste it into a section of another tree in another 
window.



I'm sure Matt and the other developers can go into more detail than I 
have here.  Also, keep an eye out for the 1.5 release.  You can get an 
alpha copy if you'd like from the developers, too.  Just say the word.

Take care,
Chris
http://www.piscoweb.org
_________________________________________________________________
christopher jones     cjones at lifesci.ucsb.edu      (805) 680-5946
marine science institute  university of california, santa barbara
_________________________________________________________________