Agenda/minutes for Device Ontology Working Group meeting 2009.06.23
Agenda
- Logistics: Welcome, Minutes Review, Agenda Review, Chat Room
- Proper use of rdfs:domain and rdfs:range: see John's overview and Bob's overview
- Status of action items
- Review ontology and recent updates
- End Logistics: Next meeting, Action items, Attendees
Minutes
Logistics: Welcome, Minutes Review, Agenda Review, Chat Room
Minutes review.
Agenda approval.
Announcement
John just wanted to let everyone know that the ontology we have produced, and the materials we've collected and created in that process, are being applied actively to the W3C Semantic Sensor Network project. Next week the W3C SSN meeting will review a variety of ontologies, including this one, to establish a starting point for their own ontology development effort.
Proper use of rdfs:domain and rdfs:range
- This discussion lasted the whole meeting, and is fully captured in the chat session at the bottom of this page.
Status of Action Items
- [Nan,Roy] Review current definitions and include others like: 'instrument', 'device', 'transducer'
- [Luis] Update observation ontology according to today's comments.
- [Nan] See what additional properties to associate to Deployment.
- [all] Review instructions and facets outline and pick pending items (and/or suggest new ones) for inclusion in ontology. Send questions/suggestions to the mailing list.
- [Carlos] Verify pending submitted suggested changes and update ontology or email questions accordingly.
- No results to report from action items this week.
Review ontology
Current version: http://mmisw.org/ont/mmi/20090609T064417/device:

- No review of ontology this week.
End Logistics: Next meeting, Action items, Attendees
Action Items
- No new action items this week.
Next Telecon Time
Next telecon is Tuesday 2009-07-07 at 1500 UTC. (1600 UTC in winter)
Attendees:
- Nan Galbraith
- John Graybeal
- Roy Lowry
- Bob Morris
- Rob Raskin
Chat room messages:
- So we are talking about http://marinemetadata.org/community/teams/ontdevices/ontbasicsproperties
- Bob Morris: http://marinemetadata.org/community/teams/ont/property-modeling (we will talk about this later. -ed)
- John: will try to take notes to reflect the thread
- John: is it philosophically OK to restrict the relations to the purposes of this ontology?
- Bob: adding one or more restrictions to a property causes the property to be not so useful to the greater world
- Rob: that's a legitimate model and choice -- but it is restrictive
- Bob: if you try to do integration with another related ontology, for building applications it is much easier to reuse if the domain is not restricted
- Rob: Yes that's true. SWEET ontology has level of abstraction in many domains that can support this.
- Bob: Question is where to draw the line to remove ambiguity?
- Roy: I find the sub-property option more attractive than the restrictions.
- Rob: Yes, it all depends where you want to apply the ontology. You don't break anything if you go back and relax the domain statements.
- Bob: Won't application writer get in trouble if code depends on that?
- (John@Roy: I agree, I hope we'll talk about that soon.)
- Rob: Relaxing is less likely to break things than adding restrictions.
- Rob: Another possibility is to set up high-level concepts, that are more general, that can be applied in a broader context.
- John: Doesn't the fact that people can treat these properties as local to our ontology (which they are) make it possible for them to reuse our ontology without suffering from our domain/range restrictions?
- Rob: Yes, that's basically the case.
- Bob: Isn't there a risk of over-complicating the model with these restrictions?
- Rob: Yes, making one property a subclass of another is pretty limited and indirect, only available restrictions are domain, range, and type. Sometimes it's hard to visualize what that will mean.
- Bob: Very hard for people to get rid of object-oriented programming model (they tightly couple properties to class membership).
- Rob:Yes, we're used to top-down/closed world design.
- Bob: Problem with property vs class issues is that you prematurely close the world. Not opposed to that (even delicately/locally), but eyes need to be wide open.
- John: how do we select from the 4 options?
- The 4 options are: remove domain/range restriction; do nothing; use class restriction technique; use subproperties.
- (We began a discussion of the class restriction concept. Bob put up the page above to help describe this.)
- Rob: Would break up first of 4 categories to include as separate item: removing just domain restrictions, as those are more severe implications on the model.
- Rob: (Most of the properties clearly suggest a range as part of the property; this is not true for domains, however.)
- (Going back to restriction discussion.)
- John: Revisit whether a restriction, which is on classes, can be used to help solve this problem. (Rob now visiting Bob's page cited above.)
- Rob: Everything on the cited page appears accurate.
- Rob: It seems the approach cited on this page is less direct, and could therefore be less scalable (in the human sense).
- Bob: Agrees, and maybe even worse than that: scientists don't tend to learn 'the hard stuff', so it makes it socially that much less scaleable.
- @Roy, Nan: how did you do on action item 1 (multitasking here :->)
- ngalbraith: I just discovered action item 1, a few minutes ago...
- Roy: Still on my 'todo' list I'm afraid. Maybe get together with Nan when she's back from sea. When is that?
- ngalbraith: Sorry, also multitasking here ... July 7.
- Roy: I'll give it some thought before then
- Conclusions will be posted shortly
- Meanwhile, any other topics?
- Roy: Not from me. Need to change trains so goodbye from me...
- ngalbraith: Nothing here. The two docs linked above are really helpful, so thanks - lots to think - or rethink - about.
- Conclusions of the discussion: (a) It would be permissible to do nothing. (b) A review is in order, particularly attending to domains, to make sure we are putting property restrictions in place that we really want to have there. (c) If we want to maintain existing restrictions while providing more relaxed properties for broader reuse, the subproperty mechanism is better than the class restrictions mechanism for most of our purposes.