If we end the year (i.e. the XG) with an imperfect ontology but know all the way and the other bits of technology needed to get to a perfect one that satisfies all use cases, then that's a more successful outcome for the one year group than a perfect bit of an ontology without having looked all the way down the road. (…of course not arguing that we have license to be sloppy or cavalier though.).
- Wan-Ju (Ketty),
- With others like Kerry, Luis and Simon maybe reviewing and commenting and I guess input all round varying depending on other workload.
Driving question is: how much time will each put in?
- Single editor is almost certainly necessary. It will be good to get consensus on that approach, and on who that editor is. I expect the editor will end up driving both the shape and execution of the process.
- The editor shouldn't be wielding too much of a directorial hand.
- Not all changes via collaborative protege, as some changes will be easier so the editor can 'just do it', and some people won't have Collaborative Protege.
- Michael would be fine with being ontology master or note taker, or both, but open for the group to propose others.
- Wouldn’t do notes using the IRC. It's too limiting, and for those sorts of notes, diagrams, scribbles, mixed text and pictures, etc. might be required.
Working in the Subgroup
Questions to be answered
- Some initial conclusions either before, during, or shortly after the kickoff meeting (either telecon or mailing list discussion):
- Do we want to align with one or more existing sensor models (OGC SWE, IEEE 1451 ...)?
- Where does system composition occur in our model?
- OGC SWE describes a process composed of processes
- others are systems of systems;
- others are instruments of sensors
- Are there any sub-domains (measurement, workflow, etc.) that we absolutely want to include or exclude?
- Are there any existing ontologies on related topics that we want to leverage?
- Is the organization of concepts in the 'potential' list good enough to start allocating them?
- A lot of those look like big painful decisions,
- We’ll be making them whether we do so explicitly, or by default.
- It would be nice if one or two of the experts could lay out the options and propose an approach;
- Or alternatively describe the approach we're taking and why, so others can say 'whoa' if they anticipate a problem. And it will help provide an explicit model for everyone's work to fit into.
- How do we collaborate in a way that moves things forward
- Even with an experienced team, evaluating and discussing each week's changes would take on too many hours. That just used up all the telecon time and all the donated time of most of the participants.
- W3C has a much more directed decision-making style, so let's be optimistic and say 45 minutes to consolidate changes -- that's still too long for progress.
- Proposed fully collaborative model: combining
- divide and conquer,
- mostly digital iteration on technical content,
- Occasional telecon 'sprints' (for lack of a better word) where we are all looking at and discussing the big picture (~ 2 hours or more).
- The alternative would be for the editor to wield a pretty firm directorial hand, so that discussions are more pro-forma rather than deeply considered and agreed. This is ruled out (see above).
- We can not explicitly discuss or present all the changes in a telecon;
- all that technical material should be presented/available on the web, with comments made against it (by whoever's interested) and
- discussed on the mailing list (see below). That will provide a historical record and decouple progress from the telecons.
- Ideally many people can progress independently without requiring explicit group consensus, at least on the phone.
- Not starting from scratch one class at a time, rather to start with a set of examples in hand and choose content from them consciously.
- If we just have one starting point and discuss it, we may not recognize the assumptions built into it.
- start with some key important ontologies and build, merge, copy, squash etc based on the input of the group
- Suggestion: the ones listed at http://marinemetadata.org/sensorontologies and http://marinemetadata.org/community/teams/ontdevices/ontdevrel
- note that Michael’s and Holger’s initial ontology partly came from following this process
- Reference list for this activity is at SSN_Key_Ontologies_Reference_List (table at the top of Review of Sensor and Observations Ontologies)
- Starting with a plenary discussion
- With all the existing ontologies in front of us,
- we can use the 'graphic lists' of ontologies on the MMI sites for a reference
- we can make a point to add any that are needed
- each one's key attributes can be briefly presented.
- Will need a volunteer to present each one
- Need to suggest a few key attributes of interest?
- With all the existing ontologies in front of us,
- Hopeful immediate outcomes
- It will be obvious where the largest chunk of content should come from for the initial ontology.
- It will also be possible to consolidate all the concepts from all those ontologies into a single list, for later disposition.
- Combine the concepts from all the ontologies with any other available concepts, to have a large set of possible ontology elements on-line
- Sources of additional concepts: MMI list of sensor facets and sources from the State_of_the_art_survey and the SSN Communities list
- Not all of this content will be used, but nice to have the reference in one place (maybe in one big vocabulary)
- This material can be organized at SSN_Ontology_Raw_Concepts_List (table at the top of Review of Sensor and Observations Ontologies)
- Ideally someone can take on that research/normalization work?
- With a core diagram and a long list of potential classes/properties (hopefully grouped),
- It is then possible to allocate resources to different pieces of the work.
- Those resources can do more investigation around their areas, to identify existing ontologies that apply.
- CVS or the equivalent is highly recommended.
- SVN is better than CVS.
- Collaborative Protégé may implement an equivalent.
Getting things started
- Take the interested parties, give ~ 2-3 weeks to review what's there and any other ontologies that they feel should be brought in, then
- spend a whole meeting (SUGGESTIONS?) discussing the facets etc that need to be added/altered, these can be listed on the wiki and marked as open, and then
- start a process of assigning as yet open issues to members who then analyse and make suggestions to the editor (see above) with a process of review/discussion (single editor over multiple editors!).
- Agree on the above
- Host a meeting to mash all the ontologies together
- Coordinate the inputs and pulling together of those people and ontologies and their brief-walkthroughs
- any on-line discussion about preferences is allowed/welcome in the meantime
- 3 weeks from that week, host a telecon where we try to consolidate into one
- Have technical material on the web
- Have discussions on the mailing list, adhering to Tracker syntax.