[Seavox] Devices

[Roy Lowry]

Hi John,

I am well aware of the MMI interest in this area and would be more than delighted for this to be a collaborative effort. Between MMI and SeaVoX we have a wide range of oceanographic field experience covering all types of sensors and sampling devices combined with the computer science/knowledge management skills of Luis and yourself amongst others.  I'd have made a direct approach, but I knew you were on the SeaVoX list.

The use cases I'm trying to address are:

1) Controlled metadata description of a mooring

2) Improving the description of what goes on during a cruise - basically implementing a SeaDataNet extension to the IOC Cruise Summary Report (the ROSCOP).  So, I need a controlled metadata description of a set of shipboard activities, including the devices deployed.

I'm up against a ticking clock with this as the ontology  is needed for the deployment of SeaDataNet version 1 schemas in December.  I have time in August/September to put in an intensive effort if required.

So, let's start an offline discussion on how this collaboration should work and see if we can jointly solve a problem that's been hanging around for far too long. 

Cheers, Roy.

>>> John Graybeal <graybeal at mbari.org> 5/16/2007 7:55 pm >>>
Roy,

Here are the conclusions I've come to after wrestling with this (and with colleagues about this) for the last 2-3 years.  (I'm Mr. Device Type at MBARI, which is to say I've gone around on this several times and no one thinks I've done much of value yet....)

1) People think of device types in lots of different ways (as you are noting), including ways that are blends of those categories.  Additional categories you didn't mention: device_data_format; device_postprocessing; device_operating_environment.
2) The categories are not hierarchical (I think maybe you meant 'roughly a prioritized order', but am not sure...)
3) Attempts to organize an ontology strictly around either operational methology or function are fatally flawed.
4) Many categories -- like device function -- are not filled out with a singular answer, even if there is just one sensor.  In the SSDS database I have maybe 5-10 examples that are multi-function.  In some cases the function is dependent on configuration, in others on operational procedure, and in others on data processing, and sometimes just on user needs.  And that doesn't even include devices like 'CTDs' and 'CTD strings', that can have multiple sensors of various types attached, or that really serve as 'modem relays' for sensor data. And it Really doesn't include devices that are really platforms with lots of sensors on them.
5) Addressing just the lists you describe, for the number of devices we are dealing with, in even an ad-hoc fashion represents a huge investment of time.

As you know, MMI tried working with sensor vocabularies once, and ever since has been promising to dig into a sensor ontology.  (Note this would seem to address more than device _types_, but in fact I think there's >90% overlap.)  We hope to bring Alliance for Coastal Technologies, and their device databases, into a collaboration to do this.

I think it will be important to (a) describe (and prioritize) the use cases which are most important to address with this work, (b) expect to spend some time working through proper categories to meet those use cases, and (c) make sure we're coordinating with other efforts, and leverage lists that already exist and fill out some of those categories. 

I hope and recommend that this be done in collaboration with the MMI sensor ontology effort, which will need to respond to the same use cases.  But I realize timing of that effort may not align with your needs.  Perhaps we can talk about this more off-line.

John


At 12:04 PM +0100 5/16/07, Roy Lowry wrote:
>Dear All,
>
>I'm now thinking about grasping the nettle of putting together a 'device_type' ontology.  There must be dozens of lists of this type around.  Most are flat or a 2-level simple hierarchy (usually implemented using compound terms e.g. bottle:Niskin) and  seem to have entity definition problems, usually with platforms or even parameters sneaking into lists primarily composed of sensors.  Definitions are either absent or extermemly parochial such as 'net used by Alain Bedo in the BOFS project'. The lists are the result of evolution rather than design which means that granularity is about as inconsistent as it could possibly be.  We need something better in BODC and I'm guessing we're not alone.
>
>As a start to the process I thought I'd like to gather opinions on the nature of the lists that should make up the ontology.  Here's my very rough straw man, in what is roughly a hierarchical order.
>
>device_category (sample collector, remote sensor, probe, sample processor, sample analyser.....)
>device_discipline (terms like SeaDataNet vocabulary L081 - biological oceanography, physical oceanography etc.)
>device_class (sonar, tide gauge
>device_subclass (single-beam echosounder, multibea, stilling well, bottom pressure recorder, bubbler gauge....
>device_type (something identified by a manufacturer and model number)
>device_instance (something identified by a serial number)
>
>I think device_instance is somewhere where I don't want to go - a global inventory of scientific instrumentation is both too much work and serves little purpose.  So, I suggest we leave that as a local - and far from trivial - issue.
>
>So, I declare the debate open.  Once we have a set of lists we can then set about the real fun of populating them.
>
>Cheers, Roy.
>
>
>_______________________________________________
>Seavox mailing list
>Seavox at mailman.nerc-liv.ac.uk 
>http://mailman.nerc-liv.ac.uk/mailman/listinfo/seavox 


-- 
----------
John Graybeal   <mailto:graybeal at mbari.org>  -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org   ||  Shore Side Data System: http://www.mbari.org/ssds