Proposed modifications to device ontology

This page is about proposed changes to the ontology.

Note: As of 2010-05-22, the proposed changes are primarily tracked using the issue tracker (component: DevOnt, label: Change), unless the change has been made without requiring much discussion.

If you have a change to propose, please open an issue in the issue tracker (preferred) or send an email to the mailing list.

See the "Format for specifying changes?" section in the f2o page for a convenient syntax to indicate the proposed changes.

This page last updated: 2010-08-09

2010-08-09

From the facets list, the following changes made today:  See 2010-08-10 agenda.

• 4.a Quality assurance procedures
  + class QualityAssuranceProcedure (subclass of OperationalProcedure)
• 4.e Maintenance procedures
  + class MaintenanceProcedure (subclass of OperationalProcedure)

• + class OperationalProcedureSchedule
• * class CalibrationSchedule now is subclass of OperationalProcedureSchedule 
• The following properties now have OperationalProcedureSchedule as domain:
  • hasEnforcementQuality
  • hasMinimumFrequency
  • hasProvides
  • calibrationScheduleHasOmissionConsequences
    which was renamed to hasOmissionConsequence (and it's not functional anymore)
• + object property: Device hasOperationalProcedureSchedule OperationalProcedureSchedule
• * object property hasCalibrationSchedule is now a subproperty of hasOperationalProcedureSchedule with the domain and range classes restricted to Sensor and CalibrationSchedule, respectively.

• 6. Manufacturer Documentation
  + datatype property: Device hasManualDocumentation rdfs:Resource [0..*]

• 7.a.2 Unique Identifier:
  + Datatype property System hasUniqueIdentifier string [0..1]
• 7.a.3 Owner
  + Datatype property System hasOwner string [0..*]
• 7.a.3 Point of Contact
  + Datatype property System hasPointOfContact string [0..*]
• 7.d.2.2 Performance/quality/known issues
  + class Issue
  + Datatype property Device hasIssue Issue [0..*]
• 7.d.2.3 Dataset links
  + Datatype property System hasDataset xsd:anyURI [0..*]

2010-06-02

See http://marinemetadata.org/community/teams/ontdevices/dosml

• * Rename class System to Device
•  + create class Component
• + create class System as subclass of Component
• * change range of hasComponent to Component
• * make Process subclass of System
• * make Platform subclass of System
  

--> DONE See http://code.google.com/p/devont/issues/detail?id=12

2010-05-22

Factor out representation of values, http://code.google.com/p/devont/issues/detail?id=11

+ class TypedValue --> Done.

+ property TypedValue hasValueType ValueType --> Done.

* make Range subclassOf TypedValue --> Done.

+ class SimpleValue subclassOf TypedValue --> Done.

+ property SimpleValue hasValue Any --> Done.

Use the TypeValue class:

+ property hasTypedValue with range TypedValue and domain the union of the following classes: -- done

• MeasurementCapability
• PhysicalProperty
• EnvironmentalToleranceLimit

* remove explict value-related properties for these as they are subclasses of PhysicalProperty: -->done

• Weight -- done
• Dimension --> done

- remove class MeasurementRange --> done
Rationale: its superclass MeasurementCapability already has a property for the value (which can be a Range, but also other possible kind of value).

2010-05-20

+ property Sensor hasSensingMethod { "in-situ by contact", "in-situ at distance", "remote" }  --> Done.
See facet 2.e.3.

* Rename class Model to ModelID  --> done.
* rename associated property [System hasIdentifier ModelID] to [System hasModelID ModelID]  --> done.
Rationale: the concept is specifically about model dentification of a system.

- remove class Feature --> done.
- remove property [Feature hasProperty Property] -- Done.
Rationale: Feature has not been used and it's not clear how it fits in the ontology; there is only a property [Feature hasProperty Property], but there is not navigation from elsewhere in the ontology to the Feature.  This concept can be re-incorporated later on if necessary.

From 2010-01-05 telecon

- remove sublasses of EnvironmentalToleranceLimit: MaximumPressure, MinimumTemperature, and MaximumTemperature  --> Done.

+ add subclasses of EnvironmentalToleranceLimit: PressureTolerance, TemperatureTolerance. --> Done.

From 2009-12-22 discussion

+ class Range with the following properties:

• unitsOfMeasure: string
• datatype: enumeration [int, float, date, time, dateTime]
• minimum: string
• maximum:string

* update MeasurementCapability and other relevant classes to use Range.

From 2009-12-08 discussion

+ datatype properties to MeasurementCapability: value,  unitsOfMeasure  --> done.

From 2009-11-24 discussion

* rename Capabilities to Capability
* rename MeasurementCapabilities to MeasurementCapability
* rename hasCapabilities to hasCapability
* rename hasMeasurementCapabilities to hasMeasurementCapability   --> done.

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.

+ class MeasurementRange subclassOf MeasurementCapabilities --> done.

+ class EnvironmentalToleranceLimit --> done.

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

* move subclasses of AbsolutePhysicalLimit to be subclasses of EnvironmentalToleranceLimit --> done.

- class AbsolutePhysicalLimit --> done.

* rename hasAbsolutePhysicalLimit to hasEnvironmentalToleranceLimit (label: hasToleranceLimit) --> done.

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

AbsolutePhysicalLimit

From this thread, 8/31/09

+ class AbsolutePhysicalLimit subClassOf Restriction
+ class MinimumPressure subClassOf AbsolutePhysicalLimit
+ class MaximumPressure subClassOf AbsolutePhysicalLimit
+ class MinimumTemperature subClassOf AbsolutePhysicalLimi
+ class MaximumTemperature subClassOf AbsolutePhysicalLimit   --> done.

+ Create datatype property: AbsolutePhysicalLimits hasSpray tolerance (boolean)
+ Create datatype property: AbsolutePhysicalLimits hasSubmersion tolerance (boolean)
+ Create datatype property: AbsolutePhysicalLimits hasOtherPhysicalLimits tolerance (John - string?) --> done.

OperationalDepth

From this thread, 8/21/09

+ class OperationalDepth subClassOf OperationalRange  --> done.

AppliedOperationalProcedure

From this email, 9/1/09

+ class AppliedOperationalProcedure
+ object property AppliedOperationalProcedure appliedOperationalProcedureSystem (rdfs:label: system) System
+ datatype property AppliedOperationalProcedure appliedOperationalProcedureDate (rdfs:label: date) dateTime
+ object property AppliedOperationalProcedure hasOperationalProcedure (rdfs:label: procedure) OperationalProcedure
+ object property System hasAppliedOperationalProcedure AppliedOperationalProcedure  --> done.

OperationalProcedure -- process #4.4

(JG, 4/26/09; amended JG 7/8/09)

+ Create class OperationalProcedure --> Done

+ Create datatype property: OperationalProcedure producesOperationalProcedureLog (0..n) string --> Done 

+ Create datatype property: OperationalProcedure hasSuccessfulCompletion (1) boolean  --> Done.

+ Create class CalibrationProcedure subClassOf OperationalProcedure.  --> Done

+ Create object property: CalibrationSchedule appliesToProcedure (1) CalibrationProcedure  --> Done.

+ Create object property:  CalibrationProcedure producesCalibrationValue (0..n) CalibrationValue  --> Done.

+ Create object property: CalibrationProcedure resultsInCalibrationAdjustment (0..n) string  --> Done.