VTC Notes - 2010-06-16

VTC June 16, 2010: Unit Registry Update

Moderator: Mason Kortz
Attendees: James Conners, Mark Servilla, Ken Ramsey, Mary Gastil-Buhl,
Hap Garritt, James Moss, Yang Xia, Kristen Vanderbilt,
Hope Humphries, Linda Powell, Duane Costa, Jason Downing,
John Vande Castle, Don Henshaw, Sven Bolhm, Karen Baker,
Jonathan Walsh, Margaret O'brien

Overview -

Goals of the this meeting: Code migration and discussion of NIS contributed
application protocols or standards.

The Unit Registry web interface is just one functional example of possible clients
that can be built using the registry

Sven Bolhm visited CCELTER, San Diego, a few weeks ago to develop a Ruby API wrapper
for integration of the Unit Registry into local information system

Management interface is up and working. Management practices need to be developed.
There are funds available for future working group focussed on this topic.

Management Interface Details:
- Changes to units are tracked/logged
- Units from mutliple EML versions, CCE, PAL, FCE and PIE have been uploaded
- Uploading of site units can be done through the interface or by being
sent to Mason Kortz

Updated documentation is available on the Unit Working group page:

The Unit Registry application source has been checked into the LNO subversion
repository and is available for checking out:

Code/Applicaton Migration -

Very smooth. Single virtual machine for application hosting. Code was checked
into network-wide subversion repository.

Who is managing the virtual machine?

System updates are handled by LNO sys-admin. Code maintenance is the
responsibility of LTER community.

Identification of errors with the current release of the web interface

Send OS and browser version number for fixing.

At this point, the ability to integrate site-specific applications into the NIS
has been identified as dependent on applications having a web-service interface.
This may change and will be the primary topic for discussion in the Web
Services working group.

This discussion could take its initial form as a web service standards document
for development within the Web Services working group.

To begin, an idea would be to circulate topics of discussion that would lead
to the document's content.

Major milestone was the service interface, not the web-baased interface.
The web service interface serves as an integration point to the rest of
the NIS information architecture.

Sven, could you describe the development of your Ruby api wrapper

The Ruby api wrapper makes calls to the registry and stores the results
locally for use in the local architecture. Updates to units will be
obtained from the unit registry. Some questions about the api interface

These questions about the api interface can be discussed within the web
services working group as a topic of standardization and integration
for the NIS architecture.

Unclear: Are the units that are in the registry already vetted?

The only units that could be considered vetted are the units from the
EML unit dictionary. All site units have been uploaded and possibly
corrected, but should not be considered "officially" vetted.

Are there plans to involve the domain scientists in the vetting process?
Some of these unit question seem to be beyond the scope if the information
manager's expertise.

Tentatively (from Unit working group discussion): There would be two tiers
that would approach syntactical and semantic question, respectively. A
running list of domain scientist could be compiled for those who are willing
to recieve emails or notifications to involve them in the vetting process.

Curious about the vetting process. The process of involving the domain
scientists in the vetting process has not been clearly defined. Maybe
an involvement through the site information management seeking advice would
be the best method to begin.

Web interface works fine in Google Chrome. Some advice would be for the
information managers to start thinking more seriously about web services.
Question: Can units maintain multiple scopes? What is the planned
usage for these scope assignments?

Currently, the scope primarily designates origin. It is really up to the
community, specifically the Unit working group, to decide what the best
way to utilize these scopes is.

The maintainence of site-specific scopes could be useful even after a site
has been vetted and assigned a scope that designates a post-vetted state.

There are mainy benefits to maintaining provenance information
during the vetting process.

Timeframes? Any goals, possibly set for the upcoming IMC in September?

A useful resource would be a link to the best practices from the registry's
management interface.

Are there plans for unit discussions at the IMC?

There is time allotted for any IM working groups, and the unit group is
on the list of potential groups.