Agenda

1. Logistics: Welcome, Minutes{link to previous minutes} Review, Agenda Review
2. Topic 1: Sonar Instance Ontology
3. Topic 2: Sensor Attributes and Categories

Minutes

Logistics: Welcome, Minutes Review, Agenda Review

. Minutes review Agenda approval 

Reviewed agenda, but not minutes. Maybe next time.

Sonar Instance Ontology

We will review application of the ontology to the world of sonars.  Bob Arko suggests reading the following to prepare:
 http://marinemetadata.org/community/teams/ontdevices/sonars

Discussion:

• Should Bob's ontology file be citing the OWL type 'device'? Bob said that using Protege he can only reference device:sensor or device:sampler from the original ontology, which is what Bob did. This seems appropriate -- if you know which category your device falls into, picking a more specialized concept provides more information than referencing the more general concept.
• If he has 12 sonars, should he have an instance file with 12 sonars described in it?  Agreed that the instances should be separate from the general device ontology. But John thinks putting each sonar description into its own instance file would be cleaner, and less likely to cause confusion about which description you were editing. (Of course, then you can't make substitutions in all 12 files at once, unless you have a nice tool like BBEdit that can do that.)
• 'not an ontology, a file of instances' can instances really be OWL files? Protege wants to be an ontology editor, tries to turns every file into an OWL ontology. This isn't necessarily bad, but RDF is often enough. (There were issues in OWL 1 with mixing instance and class relationships, sometimes this pushes you to OWL Full and sometimes it makes inferencing not entirely straightforward.) But the general statement is that an instance file can be OWL.
• Semantic Web for the Working Ontologist is helpful for the basics of these questions. Highly recommended resource for building up understanding of the technology from the ground up.  Book makes clear how instance statements ("Joe Smith plays for the American League team Detroit Tigers" can use other known ontological type relations (baseball player -> plays_for -> baseball team; American League -> is_composed_of baseball teams) to infer things like "Joe Smith is a baseball player" and "Detroit Tigers is a baseball team".
• What about tools then?  Protege is still pretty tough to use to create instance data, it could be a lot easier to edit copies of the master, once one has been created.  (Note: TopBraid composer may be broken under some Ubuntu releases, may not get fixed.)  In some communities (like biodiversity), there is the possibility of mapping from a relational system directly to filling out the ontology. Can be difficult though.  Choice between OWL and databases for capturing knowledge should be based on whether there are relations expressed -- in other words, are we making constraining type/relation statements, or just statements about individuals.
• What should be done when sonar-specific (but not instance-specific) statements can be made? Probably not put into the main device ontology, but a new type ontology can be created for sonar-devices.  A sonar-device is of type device -- or better, of type sensor -- and thereby acquires all of its statements.
• Improvement on this suggestion: By making the sonar-device ontology relatively independent of the MMI device ontology, the sonar-device ontology can be reused independently, even by other non-MMI device ontologies. Then a single class ('MMI-sonar-device') can be declared which embodies both the MMI device ontology concepts, and the sonar-device ontology.  Then your instances can use both the sonar-specific properties, and the MMI device properties. Bob Morris and John Graybeal agreed to take a cut at this for Bob A's ontology. (Bob M first. :->)
• Note that inheritance is not through files, but through specific statements within those files. So it won't really be true that an instance inherits "the MMI device ontology file"; it is instead the case that the instance of a given type ('device:sensor') inherits, or reuses, all of the statements that are valid for that particular (device:sensor) concept.  There might be declarations in the file that don't have anything to do with device:sensors, and they will have no relevance to the instance of that type.

Sensor Attributes and Categories: OOI CI Perspective

If that isn't entertaining enough, we'll review the content and organization of the OOI CI sensor specification and parameters. If I'm lucky, I'll have some interesting data here by morning:
 http://marinemetadata.org/community/teams/ontdevices/ooicisensorterms

Discussion:

• This agenda item was not discussed.

End Logistics: Next meeting, Action items, Attendees

Action Items

Next Telecon Time

Next telecon is Tuesday 2010.02.09 at 1600 GMT. (Bonus Meeting!)

Next regular telecon is Tuesday 2010.02.16 at 1600 GMT.

Attendees:

• Bruce Andrews
• Bob Arko
• John Graybeal
• Bob Morris