Main Navigation

User login

Agenda/minutes for Device Ontology Working Group meeting 2009.10.13

Logistics: Welcome, Minutes Review, Agenda Review, Chat Room
Miscellaneous
1. MMI ORR features to navigate and browse the ontology
2. How does one become listed as a contributor to the ontology?
AGU OS10 abstracts
Static vs. dynamic aspects
Maintaining the device ontology definitions
Review proposed changes to ontology
End Logistics: Next meeting, Action items, Attendees

Minutes review.

Agenda approval.

Luis: SONet meeting last week. People familiar with OBOE, VSTO, ODM, O&M. Missing aspect: context (ex., nest-tree-forest). O&M becoming an ISO standard.

MMI ORR features to browse ontologies
Becoming a contributor
- The de facto criterion has been: whoever contributes with specific additions or modifications that get reflected in the ontology becomes a contributor and thus her/his name is included in the corresponding metadata attribute.
- This will continue to be the criteria until is subject for discussion again.

Deadline: Oct. 15

Bob A. is preparing one. John, Luis, Carlos willing to contribute. [Bob notified via email]. This would be a good opportunity to understand how the device ontology can used in a real world escenario. Examining the static-dynamic aspects in this application would be interesting (see below).

Carlos tried to explain (again) what this is about. He encourages everyone to look at the threads and pay attention to elements that are concerned with supporting data management capabilities (eg., keep track where my devices are, where/when they are deployed, etc.) versus those that capture intrinsic properties of the devices. We may want to explicitly separate these two main concerns and capture them in two different ontologies that we could call:
- DTO, Device Type Ontology: to deal with instrinsic and/or manufactured-specified properties like: measurement capabilities, restrictions, where the device can be deployed, etc.
- DMO, Device Management Ontology: to provide support for device management applications, that is, support for concrete device instantitiations including properties about the status of the particular devices, where they are deployed, who deployed them, provenance information, etc.
But the DTO is also subject to changes that you may want to keep track of. Yes, you can do that; but the changes here are more of an evolution nature: you are improving the characterization (adding new fetaures, elaborating some class hierarchy, adding some properties, etc.). This is not much of a "data management" nature, but a "knowledge representation" refinement process.

http://marinemetadata.org/community/teams/ontdevices/deviceontterms should be updated to focus on the specific definitions used in the ontology. Other materials can/should be moved to other documents.
Of course, the definitions in the ontology file itself should be kept up-to-date as well. The proposal is to use http://marinemetadata.org/community/teams/ontdevices/deviceontterms as the primary source for the definitions. Then, the ontology file is to be updated from there.
Our process to update the ontology starts from the facets outline. The process involves the identification of entities and relationships and associated definitions.

Discussion

Maintaining the definitions involves having the necessary definitions starting from the facets outline.
Ideally, the ontology itself should be the primary source for maintaining the definitions. And for external users of the ontology that will be the case, of course. However, for purposes of its development, for example to facilitate review, editing, comments, etc., a page in the MMI drupal site is a better option. Note the the MMI ORR does not provide this ind of functionality.
A semantic wiki mechanism is proposed.
Note that tools like Collaborative PRotege and Web Protege would presumably be good options here. (BTW, comparing the semantic wiki and Web Protege mechanisms would be an interesting exercise but not likely to happen at least in the context of our group.)