Google "pad": https://docs.google.com/document/edit?id=1cCzYcOtSPd9PQ9f-rcNTlOHlvO7E4n...

Agenda

1. Logistics: Welcome, Minutes Review, Agenda Review
2. Recent updates
3. MMI Device Ontology - consolidated documentation
4. Instantiations
5. OGC presentation (June 14).
6. Platform, System.
7. End Logistics: Next meeting, Action items, Attendees

Minutes

Logistics: Welcome, iEtherpad, Minutes Review, Agenda Review

• google doc "pad": see link above
• Minutes review - No comments.
• Agenda approval -- topics added (OGC, Platform/System revision)

Recent Updates to DevOnt

Version 20100524T062910:

See modifications page.

MMI Device Ontology - consolidated documentation

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

• Including notes about issues/pending decisions.
• Comments welcome anytime

Instantiations

• Luis suggests: provide a CSV at the instance level; then “map” somehow to the ontology (DevOnt or some extension, eg, VaisalaWM30)
• Example: http://marinemetadata.org/community/teams/ontdevices/devontacc

• Action item: Nan and Bob A.: send sample of instances (CSV) to the list and/or Luis/Carlos.
• Instantiations not necessarily to be capture in ontology format.
• However, what about enabling reasoning/querying capability on top of the instantiations? No need to materialize the instantiations in OWL or RDF, but have some kind of ontology "view" (as mentioned in past telecons) for some external mechanism to provide the query and inference capability.

OGC presentation

(june 14). Presentation to showcase the device ontology. Luis would need concrete instances. He will coordinate with Nan and Bob A.

Platform/System revision

(some of the key points here; emails/further discussion to follow)

Luis suggests:

• Process should be subclass of System
• make possible that a platform can be a composite of platforms, so need to have Platform as subclass of System.
• This way, it will also be possible to say that a Platform canBeDeployedOn a Platform.

Carlos:

• System has been mainly motivated as the class that factors out common concerns of physical Sensors and Samplers in particular regarding the aspect of something that receives inputs and produces outputs. In this regard, System is subclass of Process.
• The composition aspect of Systems was added later on with the property hasComponent.
• Our current structure aligns well with SensorML w.r.t. to physical composite processes. (see http://marinemetadata.org/files/mmi/sml3.png which is based on this slide http://marinemetadata.org/files/mmi/sml-processes.png).
• The Platform class in DevOnt is more like a placeholder; the associate link from a System (ie., sampler or sensor) would actually be to the appropriate class in the Platform Ontology.
• In principle AFAIK, there is no intent to capture platform concerns in the device ontology; just being able to say, "this instrument can be deployed on such and such platforms" and "this instrument is deployed on this particular platform."

End Logistics: Next meeting, Action items, Attendees

Action Items

DevOnt tracker: http://code.google.com/p/devont/issues/list

• [Nan,Bob A] send instance example (in a CSV-like format) to Luis.
• [Luis] summarize proposed ontology changes regarding systems/platforms and send them to the list.
• [Carlos] complete version of ontology document
• Done: [Carlos] determine approach for capturing controlled definitions --> rdfs:isDefinedBy.
• [?] Determine license
  
• [Bob A., Carlos] look into ProcessOutput vs. MeasurementCapability related issues, especially in the context of the Multibeam ontology.
  
• [John and Reyna] Follow up on scale references

Next Telecon Time

Next telecon is Tuesday 2010.06.08 at 1500 UTC.

Attendees: