Devices Ontology WG Mtg 2008.08.19

Agenda/Minutes for Device Ontology Meeting 2008.08.19

Agenda

  • Logistics: Welcome, Minutes Review, Agenda Review
  • Review of ontology according to last comments. See this draft page.
  • Determine strategy for the ontology development:
    1. check in all versions (serially or in different branchs?)
    2. keep drafts on website for discussion; then only check in agreed upon versions
    3. other proposals?
  • TRAC strategy: I guess the expectation is to reactivate it; I can certainly create any entries that we agree on during the meetings, but is everybody actually looking at that on a regular basis? What about discussing the status of previous action items?

Minutes

Logistics: Welcome, Minutes Review, Agenda Review

Comments on Last Minutes/Last Meeting

To review: The last telecon covered a fair amount of philosophical ground, with relatively few participants. A conclusion was that it would be nice to deal with a concrete application of the ontology, as well as the abstract design. John emphasized we will not have time to 'solve the specific problem' during meetings, that the owner of the specific problem will have to invest considerable time toward moving their solution forward. Bob Arko volunteered that he had a use case, requiring categorization of sonar devices, that could fit the purpose. Since there were relatively few participants on that call, it might be worth reviewing that discussion and tentative decision. The minutes are a little weak in presenting what we were thinking about -- if we can add some more details to them, that would help provide background to the people who weren't there.

Review of ontology according to last comments

See this draft page.

  • Associate outputs & inputs to System.
  • System identification attributes (eg., manufacturer, serial number, etc) could also be modeled as a 1-to-many association with a class, say IDProperty, that would be a subclass of Property.
  • There is a time-dependent part, that is not central to all use cases (the 4 boxes at upper left) belong to the system
  • Need to be able to deal with both in-situ logged and remote streaming data. Is this central to our work/use cases?
  • Do need to be able to distinguish between system that can log internally and system that can not
  • Systems might have internal logging, external streaming, or both
  • May be associated with inputs and outputs
  • System could stand alone, if it has inputs and outputs
  • Focusing on systems will let us discriminate between different types of systems
  • Moves toward the holy grail of classification capability
  • Some discussion of similarities between this diagram and SensorML model. What are we trying to do that isn't already done with sensorML?
  • Do we want to build on the classifications that have already been made in previous work? E.g.: Sensor Ontologies: From Shallow to Deep Models (the publication itself); OWL file for OntoSensor.  Additional papers on the topic: 
  •  
    • SWW3589 D.J. Russomanno, Y. Tritenko and Q. Qizhi (2008) "A Web Service Interface for an Unattended Ground Sparse Sensor Detector," Proceedings of the International Conference on Semantic Web and Web Services, CSREA Press, Las Vegas, Nevada.
  • What are existing classification schemes? Jesper's list is often by measured parameters; so is Bob Arko's
  • Make lists of our classifiers that we use for organizing our devices, and compare them in next meeting.
  • Include use cases and previous paper 
  • If focus is on systems (eg., sensors, samplers, platforms), should our device characterization care about deployments?
  • Second diagram: consider ComplexSystem/SimpleSystem as way to capture distinction between compositional and simple systems.
  • A SimpleSystem (which would have Sensor, Sampler as subclasses for example) would have the specific ID attributes like manufacturer, model number. A simple system may also need to know firmware version (is "can system change over time?" an attribute?)   (no concrete conclusion on this.)
  • A ComplexSystem (or CompoundSystem, or CompositeSystem) is an aggregation of systems.
  • (Note: this diagram is a "class diagram", not an "instance diagram." Perhaps having some "instantiations" would help improve the design.)
  • Driving use case is one in which user is looking for data but will they use sensor ontology to do this?
  • Wouldn't they be better off looking directly for the data they are interested in directly?
  • Some look for particular pieces of kit, or other attributes
  • Design for current practice, or try to design for future practice? Have to satisfy current practices, but also be able to answer new questions better where possible.
  • Can we keep the variable for firmware out of this model, because it is time-variant?
  • Prefer fewer classes with richer attributes to big diagrams with many classes
  • What is value of serial number? Various: manufacturers do not follow identical practices re model and serial numbers, but the latter is useful for identifying instances.
  • Platforms do not have data outputs, are we agreed on that?

[Carlos] Update diagram per today's conversation.

Determine strategy for the ontology development

  1. check in all versions (serially or in different branchs?)
  2. keep drafts on website for discussion; then only check in agreed upon versions
  3. other proposals?

Opinion is that all versions should be checked in. Use either of the following mechanisms to segregate the approved versions: Either (a) tag approved versions (e.g., with "Approved 20080819"), or (b) put interim versions into branches, and remerge to the trunk when approved. Use svn to be the repository of record for these artifacts.

[Carlos] Update svn repository with version we discussed today. (And implicitly, decide whether to use branches or tagging as approval management.)

TRAC Strategy

(Not discussed.)

End Logistics: Next Meeting, Action Items, Attendees

Next Telecon Time

Next telecon is Tuesday 2008.09.02 at 1500 GMT.

Action Items

  • [Bob, Carlos] Look at paper
  • [Carlos] Update diagram per today's conversation
  • [Carlos] Update svn repository with version we discussed today. (And implicitly, decide whether to use branches or tagging as approval management.)
  • [all] Contribute list of your known classifiers for sensors and samplers

Attendees

  • Bob Arko
  • Bruce Andrews
  • Luis Bermudez
  • John Graybeal
  • Roy Lowry
  • Carlos Rueda
Posted August 19th, 2008 by graybeal
in