Agenda

1. Logistics: Welcome, Minutes Review, Agenda Review, Chat Room
2. Object vs. datatype properties
   • The issue: Having to instantiate classes where direct datatype property assertions may be more appropriate, efficient, less-cumbersome, and/or reasonable.
   • Possible approaches - please review
3. Review of Device Ontology instantiation exercises
4. Updates to the ontology
5. End Logistics: Action items, Next meeting, Attendees

Minutes

Logistics: Welcome, Minutes Review, Agenda Review, Chat Room

Minutes review.

Agenda review.

Chat room, Etherpad.

Object vs. datatype properties

• Primary concern is to capture the semantics across the various concepts.
• Classes and object properties is the the mechanism to capture this semantics.
• Scalability: important but a secondary concern.

• Add datatype properties to MeasurementCapability: value,  units_of_measure
  

Review of Device Ontology instantiation exercises

• From Bob Morris' instantiation exercise.
  
  • Instance ontology created using TopBraid (OWL and N3 formats).
    A corresponding diagram:
    
  • 
    
    

Updates to the ontology

From last meeting:

* rename Capabilities to Capability
* rename MeasurementCapabilities to MeasurementCapability
* rename hasCapabilities to hasCapability
* rename hasMeasurementCapabilities to hasMeasurementCapability

From 2009-09-29 discussion

* move the OperationalRestriction subconcepts (except OperationalRange and its subclasses) to the same category as Weight, Buoyancy, Dimension, Material, ie., as subclasses of PhysicalProperty.
The classes moved were: SelfPoweredOperationTime, PowerRequirement, DataStorageCapacity, MinimumOnTime

+ class MeasurementRange subclassOf MeasurementCapability

+ class EnvironmentalToleranceLimit

+ datatype property EnvironmentalToleranceLimit hasConsequence enumeration { "damaged," "stop working", "unreliable measurements." }

* move subclasses of AbsolutePhysicalLimit to be subclasses of EnvironmentalToleranceLimit

- class AbsolutePhysicalLimit

* rename hasAbsolutePhysicalLimit to hasEnvironmentalToleranceLimit (label: hasToleranceLimit)

+ datatype property Sensor hasEngagement enumeration { "active", "passive" } (functional)  (2.e.2)

From this thread, 8/31/09 --with EnvironmentalToleranceLimit instead of AbsolutePhysicalLimit

+ Create datatype property: EnvironmentalToleranceLimit hasSprayTolerance (boolean) (functional)
+ Create datatype property: EnvironmentalToleranceLimit hasSubmersionTolerance (boolean) (functional)
+ Create datatype property: EnvironmentalToleranceLimit hasOtherPhysicalLimits  (string)

Updated ontology version: http://mmisw.org/ont/mmi/20091208T071936/device
Diagram:

End Logistics: Action items, Attendees, Next meeting

Action Items

http://code.google.com/p/mmisw/issues/list?can=2&q=label=OntDev

Attendees:

• Bob Arko
• Bob Morris
• Rob Raskin
• Carlos Rueda

Regrets: Nan Galbraith

Chat room messages:

[8:22] Bob Morris: Getting a head start
[8:28] Carlos Rueda (MBARI): Hello everyone -- again, apologies for the very short notice.
[8:28] Bob Morris: Based on http://marinemetadata.org/community/teams/ontdevices/ovdtp I am a little less skeptical about the "Object-Datatype" approach in that it looks at first sight like it is neither more nor less scalable than the pure Datatype approach. The biggest trap I can see in it is the temptation to fall into declaring domain and range for hasMeasurementCapability, but maybe this trap is also true for the pure Datatype approach.
[8:29] Bob Morris: Will call in now
[8:29] Carlos Rueda (MBARI): OK

Next Telecon Time

Next telecon is Tuesday 2009-12-22 at 1600 UTC.