See also: IRC log
<scribe> Scribe: Jeff Waters
<scribe> ScribeNick: jeffw
<dmcgarry> Good morning Jeff
Notes for the next incubator meeting, June 10th, 2010 We're at a nice point now where we can begin modeling our use cases. We're familiar with the eXtreme design methodology, the use of the Neon Toolkit and XD plugin, and we've reviewed the decision components and use cases. Three of us picked use cases to begin modeling: Don with Situational Awareness, Eva with Open Linked Data, and Jeff with Information Flow. Anyone who is interested and hasn't picke
marion: perfect topics for ICCRTS in 2011
dmcgarry: update on sitrep, the
oasis sitrep standard is designed to be able to transmit these
basic report types, sitreps geared toward certain
... I advocated for (A) we should have the ability to have field operators to send simple reports in addition to the formal ones; the structure looks like there is a root set of
... elements across the report types, I have a list of the report types that I could mention, I'll pull it down real quick, one of the subreports is the simple sitrep, hey I'm this operator, this is the info I observed and if I have it here is the incident id
... like Cursor on Target but geared around incident as opposed to apoint, others are response resource report, casualty report, a more detailed subreport situation information
... like when it was declared a disaster, is there a staging area, and final report type is management reporting summary that when the praticitioners designed the requirements for this thing
... they created this wish list like hazard information, what infrasctructure impaced, etc. and the reason I call this a wish list is because from my experience people want this but it doesn't happen for first couple of days
... we stuck all of this in one report type so it didn't clog up the others. Where it stands we are trying to determine required v. optional, so it can go on from there.
jeffw: how reusable are core components for other domains?
dmcgarry: for other situation
reporting, you could just implement the root message with the
basic report type. The only thing that is in there that might
be an implementation issue is that incident id is a required
... but if you don't know it, you can put in unknown. The stuff in the basic report type is who is sending the info, where are they, what do they need, when are they going to contact you next and
... a free text area for observations. Maybe some enumerated types.
I was wondering about flexibility with ValueListURI concept of pointing to an externally managed list of terms rather than a constrained enumerated types
dmcgarry: issue is terminology
mapping and if you do that on the fly, that's a problem when
people come together for an emergency
... my colleague had a visual graph that you could draw lines between what matches, that's my concern
... I definitely want to see as we go ahead, hey this thing is pretty flexible, how can we apply it to a more abstract pattern than just what it is now
Regarding the Information Flow use case, I have made some progress. The use case itself is documented on this wiki page http://www.w3.org/2005/Incubator/decision/wiki/Use_Case_Measuring_Info_Flow and the progress is summarized on another wiki page available here: http://www.w3.org/2005/Incubator/decision/wiki/Use_Case_Info_Flow_Progress.
I'll summarize verbally what's on that progress page and then mention a few issues. In general, I was able to import and specialize the Transition pattern, and then create instances of time intervals, decision states, transitions and trigger events, and then create a sample SPARQL query to run against the dataset.
Diagrams are available to show the progress on the page mentioned. As soon as I work through a few more cleanup issues, I should be able to post up the ontology file itself.
jeffw: (reported on status)
(discussed schedule, see notes below)
dmcgarry: I just got put in
charge of informatin sharing experimentation environment lab at
... we have a lab, potential to connect to outside sources and potential to connect to other IFCC labs in Mitre
... what makes this different than any other lab, we have the standard strong server for many vms but also the ability spin up a quick virtual lans and have simulated barriers or guards
... and the lab has the ability for folks to watch what is on players' screens, so I was planning to run an experiment in August between a couple of our locations
... the national planning scenario was one I was interested in exploring, decisions play a key role in that, so if we can come up with a couple prototype standards and tools
... then we could use it in the experiment. Here are the different little use cases and take a crack at how we will move around and visualize it. Just try to come up with something.
So in summary, we've discussed the importance of moving ahead with our modeling efforts, Don with Situational Awareness, Eva with Open Linked Data, Jeff with Information Flow and
we have some milestones to shoot for to help motivate us, including an experiment in August at Mitre, the Virtual Golden Phoenix work in July and beyond, and the potential working session in the fall.
Regarding schedule for the incubator, in theory it's 12 months and we started in April, but really six months would be a better plan for accomplishing our core work, so that means we should try
to make as much progress as possible in next month or two. Then we can consider whether anything we've come up with merits consideration for recommending it be moved to
a standards track.
On a separate matter, I mentioned a couple issues that arose when I was doing the Information Flow use case.
One of the issues, and why I haven't yet uploaded the ontology, is that it was interesting to see the strengths and weaknesses of gui tools for editing the ontology. In some ways, the guis are cumbersome if you know what you want to do and especially if copy/paste can be done to quicky generate instances.
One of the interesting disadvantages is the issue of generating unique ids for the urls. That is a little harder to do manually. Another issue for me was that I had some odd annotations (comments/labels) showing up when I specialized. I'm sure it was operator error but I want to repeat the process to see for sure. Another interesting issue is the use of meaningful url names which is not, I believe, an advisable practice (since it's an inappropriate place
handy when you are trying to create examples and work through initial drafts.
Meeting adjourned at the regular time, a few notes were added later.
Don reported out on his Situational Awareness work that he is starting to move forward and will have more to report next time.
Jeff mentioned that Eva was unable to attend but was moving forward with the Open Linked Data.
Marion will review status and assist on one or more of the use cases.
rrsagent set log public
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Jeff Waters Found ScribeNick: jeffw WARNING: No "Present: ... " found! Possibly Present: ScribeNick dmcgarry inserted jeffw marion You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://www.w3.org/2005/Incubator/decision/wiki/Decision_Mtg_6_Agenda Got date from IRC log name: 10 Jun 2010 Guessing minutes URL: http://www.w3.org/2010/06/10-decision-xg-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]