Dear All,
I have followed this discussion and have the following comments:
More than one vocabulary will always exist. Hard to say it, but is
true. I agree with Roy that what we need is a mechanism to link two or
more vocabularies. Of course with more than an "equivalent" relation.
SKOS is under development but we can learn a lot from them. In SKOS the
following properties are available: exactMatch, narrowerMatch,
broadMatch, mimorMatch, majorMatch and AND and OR. At MMI, we have
three relations implemented :narrowerThan, broaderThan and sameAS.
First two from DC and the last one from OWL. For interoperability, we
need the following:
- Unique identifiers for each term in a vocabulary ( which we have most
of the times) and I strongly suggest URN for this purpose.
- Able to match terms from two vocabularies with "sameAs" and this
implies that the units must be the same. What happens if the units are
different (e.g. m vs Inches) ?. Then units should have also a unique
identifier, or consistent string representation (in each system) to be
able to reconcile these differences.
Cheers,
Luis
On Jun 17, 2005, at 12:52 AM, Roy Lowry wrote:
> Nan/Jonathan,
>
> Following our discussions at IMDIS/GO-ESSP I think the OTS is an area
> where we need to look carefully at the role of the BODC Parameter Usage
> Vocabulary in the CF standard.
>
> I think Jonathan's suggestion of extending the Standard Names to cover
> the requirements of OTS goes against the idea we had at GO-ESSP to
> avoid
> increasing the area of overlap between the two vocabularies.
>
> What I think we need in OTS is a mechanism to link to either vocabulary
> or perferably both. My suggestion would be for a field somewhere in
> the
> standard to locate the 8-byte BODC parameter code with an option to use
> the full_title term from the vocabulary for the CF long name. This
> would allow the data originators - ie those who know their data best -
> to establish the vocabulary mapping.
>
> The weakness with this is that the structure implies the relationship:
>
> BODC Parameter Usage Vocabulary term = (ie is exactly the same as) CF
> Standard Name term
>
> It is glaringly obvious to anyone who has looked at the vocabularies in
> any detail that this such perfect correspondance is far from universal.
> What we really need if we have terms from the two vocabularies
> describing the same variable is a standardised statement of how these
> descriptions relate to each other based on OWL or something more
> restrictive (but specifically targetted at the problem) like SKOS.
>
> Cheers, Roy.
>
> Nancy Galbraith <ngalbraith at whoi.edu> 6/16/2005 3:35:12 pm >>>
> Thanks for bringing OTS into the discussion, Steve, and thanks for your
>
> comments
> Jonathan.
>
> Our operational data is so much simpler than that of some other CF
> users
> that it
> sometimes seems we don't exactly fit here, but the CF community and
> resources
> have been really helpful, and your standard was the obvious choice for
>
> our data.
>
>> But instead they could be CF-compliant by dimensioning
>> the data variable as (time,depth) and giving it a coordinates
>> attribute to point to auxiliary coordinate variables of lat(time)
>> and lon(time).... These are what CF calls "scalar coordinate
>> variables" and they avoid introducing a size-one dimension
>> just to attach coordinate info.
>
> Maybe I didn't think this through well enough, or I completely missed
> one of
> the basic CF concepts. I somehow missed that CF files should "avoid
> introducing
> a size-one dimension just to attach coordinate info" and thought that 4
>
> dimensions was
> a reasonable way to go, as it gives you the overall size of the dataset
>
> in one query.
> For mooring data, this seems to make perfect sense, or maybe I just
> expect it because
> it was standard in our old NetCDF implementation, EPIC.
>
> We have not ruled out files containing data from more than one platform
>
> - as we
> sometimes deploy arrays of sensors. Such a file would have lat/lon
> dimensions > 1,
> in all other files these dimensions would be 1. This does lead to a
> problem with drifters,
> where the X and Y dimensions of the measured parameters are 1 but lat
> and long are
> of dimension T.
>
>> CF provides a method to attach quality-control info to data
>> variables, which OTS could extend to meet their needs in this
>> area (CF 3.4).
>
> The CF scheme for QC might help us give the different data providers
> more flexibility
> than having a defined table as we currently do. The down side is that
> if
> the flag_meanings
> are not defined as part of the standard, they can't be interpreted by
> software; I'm not
> sure how CF users implement this.
>
> We also have some data sets (mine, for instance) where QC information
> is
> more
> logically supplied as an attribute, because the data is interpolated
> over time to correct
> clock drift after initial QC procedures. The original individual points
>
> are gone,
> and point-specific QC becomes meaningless.
>
>> They probably would like some additions to the standard
>> name table.
>
> I haven't had a problem finding standard names for our parameters yet.
> I'm
> still hoping the udunits system will at some point include conductivity
> and
> salinity units other than 1, though. Meanwhile I'm dealing with this
> by
> specifying CF-compliant "units" and "text_units" that are useful for
> labels
> and don't have to be accepted by udunits.
>
> Cheers - Nan
>
>
> *************************************************************
> *Nan Galbraith Upper Ocean Processes Group *
> *Woods Hole Oceanographic Institution Woods Hole, MA 02540 *
> *************************************************************
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
---------------------------------------
Luis Bermudez
Software Engineer
MMI Liaison -
http://marinemetadata.org
bermudez at mbari.org
Tel: 831-775- 1929
Monterey Bay Aquarium Research Institute
Received on Fri Jun 17 2005 - 10:33:29 BST
