Karen and I have been running into an annoying problem. Anytime I create a new directory/file on iocean, its default permissions are 755. Thus, it lacks the group write permission (775). This is particularly annoying when working together on group projects. It requires either changing permissions on all affected files using chmod 775 [file], or using the sudo command to overrule the permissions completely.

I wanted to see if there was anyway to solve this problem at the source. Why not have newly created directories/files contain the proper permissions at the start? I did some research and discovered the umask command, which sets a file’s default permissions at creation time.

By default, the umask setting is 022. It ’subtracts’ 022 from 777, giving all newly created files a 755 permission. Changing the umask value to 002 makes the default permissions 775, which is what we want.

I added a line to my .bash_profile file that changes the umask: umask 002
This changes my umask value everytime I login to iocean, so I never have to do it manually. (If anyone reading this wants more information about this process, please ask in a comment, and Jerry, Mason, myself, or anyone else will be able to help.)

Note: It is sometimes important to have personalized folders to which only you want write access. Be careful when changing the umask value if the bulk of your work involves personal data. Since we are mostly living in a collaborative environment, it makes more sense to change the defaults so that file sharing becomes easier within groups.

Another Note: I created aliases to make it easier for me to change my umask values.
alias open="umask 002" # Collaborative
alias shut="umask 022" # Personal

I have these aliases stored in my .bashrc file, which is loaded by .bash_profile on each login. Using these aliases, I can simply type “open” or “shut” as commands to change my umask value, making it easier to transition between collaborative vs. personalized work.

Some thoughts/questions that popped up for a new user writing a blog entry:
-there’s no ‘write entry’ on front page; have to enter the murky realm of ‘admin’?
-wondered what ’save draft’ would do but didn’t want to take time to find out
-how best to deal with a bulleted list?
-practice with editting earlier entries
-possible to print a single entry?

An informatics seminar was given by Roy Mendelssohn, Env Research Division, SWFisheries Center, Pacific Grove on 18August05 at the NOAA Southwest Fisheries Science Center conference room titled “Data Integration and Interoperability in PACOOS, in NOAA, in IOOS and Beyond”. From the perspective of a domain scientist engaged with data analysis work and participating in ongoing national data committees, he provided insights drawing on recent experience putting together a working data system model in a short period of time.

Some informatics extensibility todo’s
-make rdb spatially enabled
-make metadata fgdc compliant
-make semantic & syntactic metadata conform to a given std
-take steps now to ease implementation/federation
-participate so to influence final requirements

Some unresolved issues
-how to stop people from misusing data
-how to balance serving products versus data
-how to balance data release versus data quality
-where do heavy lifting so to build in flexibility: local system or transport layer

Some notes and notions
-renaming: NMF->NOAA Fisheries->National Fisheries Service -> One NOAA
-DB systems have data and metadata separated while netcdf/hsd are self-describing file formats that have them reside together.
-data redundency as strategy for serving data in different ways
-dimension information; HDF not allow you to share dimensions in viewing cruise data but must choose view, ie all data at one station or look across stations

Three taking-back steps to avoid
-focusing on maps (describing) rather than data (analyzing)
-focusing on 2D (GIS) rather than 4D (netcdf space and time)
-using data strctures that have no scientific meaning (ie polygon or vector in GIS where no one collects a polygon)

Interoperability involving 3 interrelated issues:
-have the DATA
-describe the data with METADATA
-produce something that works DATA TRANSPORT

Since categories matter, note that DMAC has 6 categories of expert teams
http://dmac.ocean.us/dacsc/about_steering.jsp

• standards process
• archive
• sys eng/enterprise architecture
• modeling
• metadata & discovery
• data transport and access

I currently use the ichat client with AIM on my mac but seems the new chat protocol - jabber - may bring some changes. Here’s my understanding of platform/client/protocol configurations:

• mac-panther/ ichat/AIM-AOL, MacAccount
• mac-tiger/ichat/AIM, Mac, Jabber
• open source/GAIM/Jabber
• google/googletalk/Jabber
• windows/AOL msg, MSN, Yahoo msg/AIM

Wonder whether we will eventually abandon AIM and get gmail accounts since google has the googletalk client using the jabber protocol!?

I (finally!) upgraded the iMac here to Tiger. Spotlight is indexing right now, and Software Update is running to get those patches for 10.4.2.

This a reminder that we should upgrade our other machines as well, assuming we have the licenses.

If you are an avid reader of this blog, then all 2 or 3 of you may have noticed a few recent changes. In particular, these changes are the header/logo, horizontal navigation tabs, and the sidebar navigation.

You can view “before” and “after” snapshots of this blog here.

The categories page shows a listing of all posts sorted by category and ordered by date.
The posts page shows a listing of all posts ordered by date.
The pages page shows a listing of all static pages embedded into our (dynamic) blog. We only have one such page thus far, that being the Screenshots page linked above.

The tabs may be useful in helping keep track of your location. As an example, the posts tab becomes active when viewing a single post (with or without comments). Before this feature, it was sometimes difficult to determine what type of page you were on, requiring you to scroll down and see.

The sidebar navigation has an addition of links titled “Active Threads”. This list shows the 6 most recently commented posts, with the most-recent on top. This should help us keep track of where the latest commenting activity is.

Happy blogging!

I wrote a simple plugin that sends an email notification for new comments posted, but it only emails those users who have already posted comments to the thread. In the case below, Karen, Jerry, Lynn, and myself will all receive email notifications when a new comment is posted. Mason and Jesse (the rest of our user-base… for now) would not receive emails. (Btw, there are new comments posted by Lynn and myself… consider this entry your notification).

Jerry and I both foresee that these email notifications may become annoying and spam-like. In this case, we can assume that we are all actively using the blog and thus should not need reminders to constantly check it. Once (if) we get to that point, we can remove email notifications.

The oceaninformatics mounted directory (…/projects/oceaninformatics) is cluttered with unorganized, temporary, and obsolete data. This makes it difficult to filter out a needed file, or to determine where to save a given file. I feel it’s time we add some conventions on how we structure our shared working environment. We may also consider using conventions for versioning our data, or perhaps even using Subversion to do some dirty work.

Here’s my proposition: All data belonging to specific projects reside in a folder with the project’s name, first letter capitalized. Examples: PersonnelDirectory, Dictionary, LTER, etc.
I suggest using a CamelCase naming convention (no spaces between words) to make things easier. These folders can be referred to as Project folders.

We may also have a set of “data” folders, where each data folder contains a specified category of data. Examples: photos, schemas, files, etc.
All data folders names are lowercase.

Any Project folders can contain other Project folders and data folders. Data specific to a project is stored in a data folder under that Project folder. Example: The source photos used for making thumbnails for the personnel directory are stored in: oceaninformatics/PersonnelDirectory/photos/src. Likewise, the thumbs may be stored in: oceaninformatics/PersonnelDirectory/photos/thumb.

Project folders may contain “sub-projects”. Example: LTER may contain the Project folder “IM Meeting in Montreal Aug4-7 2005″.

This rearrangement of folders and files is fairly trivial. I am not interested in creating a strict convention for organizing project-specific data. Rather, I would like to invoke a simple working-space skeleton that organizes our projects and data in a logical sense. This approach works well for static data files (files and documents that never change); however, we need to determine a better way to store our dynamic documents (files we edit… a lot!).

Our existing method of storing dynamic documents is to put them into personalized tmp folders (e.g. temp_ksb/, temp_srh/). We also have personalized working folders (i.e. working_lry/) used for storing “up-to-date” files. I dislike the concept of using personalized folders in a collaborative working environment. That’s what our home directories are for. I feel we should dismiss personalized tmp/working folders in favor of keeping our documents organized by topic, not by author.

(On a side note, what’s the difference between a temp folder and a working folder? To me, they are equivalent. Both types of folders tend to get bloated with “up-to-date” documents and archived revisions of those documents.)

That being said, I still see the value of a single tmp folder. It is a useful place to store documents, only with the anticipation of moving them elsewhere or trashing them.

It may be a good idea to embed author names and revision numbers into the file names (of dynamic documents), particularly when taking turns editing files. For example, I create file A and save it as: A_srh01.doc. Karen edits it and saves it as: A_ksb02.doc.
Because we are sharing documents without the aid of a file management tool, we must adhere to some kind of naming convention to keep our revisions ordered.

We may also consider using Subversion to version some of our files. Though it comes at the expense of extra overhead in the workflow process (the advantage we have now is that we are using no tools!), it efficiently saves each revision we commit and enforces us to log comments for each revision. Even if we choose to bypass Subversion and continue with our tool-less approach, we should at least practice the conceptual ideas of file versioning that Subversion offers.

This one’s for Karen.

We’ve experienced issues with trying to open files in Excel that we know should open. The common example is with csv files. Say we have a file named data.csv that we wish to load into Excel. We choose to Open a new file. At the top of the window is a drop-down selection menu to Enable certain files. The default choice is “All Readable Documents”. This choice is no good, however, as our data.csv remains faded in the finder window, and we are unable to select it.

At this point, our normal workaround is to add a.txt extension to the file, so that data.csv becomes data.csv.txt. This activates the file in the finder window, giving us the ability to open it. This workaround, while trivial, is tedious (when dealing with lots of files) and also unnecessary.

Instead of changing file names, you can change the Enable drop-down menu to “All Documents”. The data.csv still remains faded in the finder window. However, it is now selectable and can be opened in Excel, without a .txt extension.

In my opinion, this is a poor design of the application interface. Faded file names usually means that a file is not selectable. When enabling “All Documents” in the Open window, the data.csv text should appear activated as a visual cue that I can now select on that item. (Note: The icon of the data.csv file does appear activated at this step. It is only the file name text that remains faded).

I removed the Xoops CMS from underneath the interoperability site. The url remains the same:
http://interoperability.ucsd.edu

These pages are purely static, written in php but with no database back-end, meaning that all content is hard-coded in the html (including the old wiki pages). There is no longer an authenticated user-base, so all pages and content are readable by the public. Future plans include the addition of a blog (another instance of WordPress), and a file upload/download manager (similar to the CCE iForum).

The old Xoops site is still online, with the new location:
http://oceaninfo-dev.ucsd.edu/interoperability

Development work for the static site will continue at:
http://interoperability-dev.ucsd.edu

Future development plans include adding a breadcrumb trail on the pages, and versioning the source code using Subversion.

EDIT - srhaber 8/19
I added the breadcrumb trail to the new site. I had trouble adding this the other day, thinking it was a php include path problem. Turns out I was just missing a helper function in the code for the breadcrumb function.