Devices Ontology Working Group Meeting 2007.09.25

• Google docs is out, because there are licensing conflicts in Europe.
• MMI wiki is good for serving files and making information available, not so good for high-interaction collaborations.
  (But John will grant editing priveleges to the devices ontology folder to all participants who are members of MMI.)
• Ontologies should be version-controlled and well-presented to non-technical folks.
• Subversion (SVN) is nice version control system, accessible in nice way with various clients.
• TRAC is nice problem reporting/discussion system, well integrated with Subversion.
• No strong candidates for drawings (Protege drawings done with plugins, and not real-time) -- check out Inkscape.
• Luis can serve ontologies in nice way for viewing on site.

[Luis,John] Set up TRAC and Subversion for OWL and text documents, and describe a process. Email everyone to review it.

No one knows a better tool than meetomatic for creating meeting times. Amazingly, everyone present agreed on a meeting time. We expect meetings will be roughly every 2 weeks, but will discuss this further as needed. We agreed to use GMT as the time to specify meetings, and expect telecon participants to do their own math. (Note that GMT time must change from summer to winter, if we want to keep the northern hemisphere schedule roughly on the same local time schedule. Apologies to people in the southern hemisphere....)

Meetings will be every other Tuesday at 1500 GMT (summer), and will shift from summer/winter to roughly follow northern daylight savings time. We will adjust the frequency as seems best.

Confluence of 3 things: more observing systems are using and referencing sensor information; standards like SensorML and TransducerML are available to describe sensor information; vocabularies are being created that represent some sensor information. It's a good time to start this; as far as we know no one else is doing so.

What are the big observing systems under development doing (and are they participating)? We think they all see the need for this work, appreciate that we are doing it, and are likely to participate and/or use what we are doing. We think they are not actively pursuing anything like this, and do not have anything like it budgeted or scheduled. Getting them to affirm this is a useful exercise.

[John] Get statements of agreement from other organizations.

Are there no existing standard vocabularies or ontologies we can reference? There are many vocabularies, and we reference them from these pages. But there are not any that I would call a standard (using criteria or either approval process or rigor), though communities or projects may rely on them. We do intend to use all these references to jump-start this work. (And it may be worth exploring future standardization options.) We would use and reference existing ontologies where possible (e.g., SWEET), rather than reinvent them. Note also that we are collaborating with SeaDataNet in this sensor work, hopefully in a way that maximizes mutual progress and minimizes duplication. (More on those details later.) OGC is not working on vocabularies, just on the frameworks within which those vocabularies are useful.

The proposed main goal is as described on the front page:

It would seem that we do not have much detail about how users would want to use this work. Some use cases or applications that would use it will help us know how to proceed. Please make such use cases relatively simple descriptions, ideally following a common template.

[Luis] Create use case framework.

Sometimes you say 'sensor' and sometimes 'device', which in our mind includes samplers. Are we dealing with sensors and samplers, or what? The proposal is to deal with both; while many on the line are sensor-centric, a fair number also have to describe samplers. (A 'sampler' was defined in this call as a device which picks up a physical thing.) Although John slips and uses the word sensors a lot, generally he means devices in general.

The group will deal with devices, to include sensors and physical samplers.

The goal appears acceptable as discussed, but more work on use cases is needed.

[John] Update the Goal section and circulate it for further comment.

Luis outlined two approaches, a rigorous ontological approach focused on developing properties, or a more incremental approach that focused on hierarchies and later identified properties from that. Could we do both at the same time? John offered the experience of the platforms work (not yet complete), in which properties proved a very difficult nut to deal with; he thinks sensors will be considerably more complicated, so this could take a lot of time to think about properties from day 1.

How do the steps of these two approaches differ? Step 1 (list of sensor types) is useful in either case; in the formal approach the work would jump to step 5, creating and designing properties directly.

Would we be building a single monolithic ontology, or modular ontologies? A preference is for modular, linking at the top level (reflecting high-level categorizations). The challenge is to do this when you don't know for sure what the 'right' high-level categories should be, or multiple users might divide the space using different categorization schemes. But cross-linking multiple shallow hierarchies felt better to many participants than deep, highly-linked relationships in a single structure.

In any case use cases will help identify where we need to go, and should be a first step.

Luis and John have a lot of action items, as outlined above, and will solicit inputs in particular areas (e.g., use cases) once procedures are in place (hopefully within a week). (Note that this is not a full-time project for either one, so everyone will be asked to help out as best they can.) This will probably be sufficient for progress for the next two weeks.

William van der Hoeven offered with Pieter Haaring to present a diagram of a different approach that would focus more on the variables produced by instruments. This will be welcome, and will likely be used to begin the discussion of categories that may be identified when considering sensor types.

The next meeting will be Tuesday, October 9, at 1500 GMT. (You may be interested in timeanddate.com for looking up your own time!)

Others may have been on the line in addition to this list; please contact me with additional names.

• Derik Barseghian
• Luis Bermudez
• Eric Bridger: Gulf of Maine Ocean Observing System (GoMOOS). Participant in the OOSTethys OGC Ocean Interoperability Experiment to test Sensor Web Enablement (SWE)
• Surya Durbha
• Jim Ferl
• David Graham
• John Graybeal
• Eric Guillemot
• Pieter Haaring
• Willem Van Der Hoeven
• Roy Lowry. British Oceanographic Data Centre. Interested in developing established (but flawed) controlled vocabularies to describe devices in BODC internal and European Union SeaDataNet project metadata.
• Stephen Miller
• Bill Moser
• Oliver Newell
• Benoit Pirenne
• Mark Schildhauer
• Matt Smith
• Jesper Zedlitz