Contents

Attitude

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.).

Proposed Subgroup

Holger,

Michael,

John,

Wan-Ju (Ketty),

Oscar,

Raúl,

Kevin,

Krzysztof,

Arthur,

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?

The Editor

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.

Collaboration

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.

Process

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