NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Heres my spin on this idea. Its a lot more ambitious than what Steve is talking
about, and perhaps not even the same thing. I guess its pretty much what Tom W.
was talking about. This whole thing is obviously related to the distributed data
/ universal resource naming problem.
--------------------------------------------------------------------
We want to make mappings from the data field names embedded in our various
data sources to some reference database of semantic descriptions of the
quantities.
There are two motivating examples:
1) what the hell is field "BLARFL" in this dataset?
2) does this dataset contain the field "latent heat of blarfication"?
The mappings must be maintained by various people, hopefully by the data source
providers. The reference database might be centralized, though it would be
better if it allowed distributed maintainence.
It seems clear to me that much of this will be discipline-specific, and we
might as well make someting work well for meteorology, and even for our
particular data sources.
You could allow subtyping, so you know that "latent heat of blarfication" is
a subtype of "energy".
A reference quantity has a unique identifier, a canonical name, a description
which attempts to say as elegantly as possible its meaning, dimensional units (a
la Tom W), and standard units, and what else?. ( I dont understand what the
"default set" is, just the default storage data type like float or double?)
You might also like to see a list of synonyms for it, which might mean all of
the data source names that refer to it. This implies name space management for
the data sources.
A mapping database accepts a data-source specific field descriptor and returns
a standard reference quantity object.
This package is more general than visAD, and should be accessible to people
not using visAD. However, a visAD core package that accesses it is a Good idea,
and it may be first implemented within the visAD framework. Similarly, a
java-only implementation is ok at first, but the design should allow eventual
access by anyone, probably via CORBA.
visad archives: