I recently submitted a response to NASA's RFI for Asteroid Observation and Characterization Ideas. I was invited to present at the Asteroid Initiative Idea Synthesis Workshop where I presented a small portion of this idea. This is the complete presentation which may help fill in some of the blanks from the shorter version of the talk.

1. Observation Support
Concept
A System for Research Collaboration
http://www.stormbourne.com
Jeff Mitchell

2. I have a concept for an on-line research
collaboration system. I envision this concept
creating a highly interconnected network of
researchers, volunteers and facilities. My goal is
to enlist the help of domain experts and scientist
in the final design phase of this system. By
focusing on what is possible for such a system, I
hope to inspire this engagement.

3. How Can I Help?
One possible way I can contribute is to provide a
workflow solution. This solution could allow a deep
level of coordination among researchers, volunteers,
and facilities. It could also provide interoperability
solutions for dissimilar software systems and data
sources.

4. System Goals
• Facilitate Communication
• Increase visibility of lines of research to the public and
the observation and research community.
• Remove barriers to participating in projects that could
benefit from volunteers, or a wider base of professional
researchers.
• Provide equipment coordination and computational
support through interface standardization
• Use the power of a “research network” to uncover new
insights and relationships among research projects

5. Facilitate
Communication
• Provide a single point of focus for a project’s
status.
• Quickly identify relationships between projects so
that duplicate efforts can be identified.
• Provide very detailed chronological records of
events and discoveries.
• Allow a principal researcher quickly promote the
urgency of a given task or subproject to the
projects network.

6. We need to make sure that we reduce the on-
boarding work for the principal research team so
that volunteer’s contributions result in a net gain in
productivity. Also the most valuable volunteers are
most likely very busy individuals as well and the
quicker they can become productive the better.
This system should create an efficient on-ramp so
that the forward progress of a project isn’t
hampered by the merging of new participants with
the project.

7. Remove Barriers to
Participation
• Would allow prospective volunteers to watch and
learn before attempting to contribute.
• Knowledge transfer to the project’s network
becomes a force multiplier for the researcher.
• Education and on-boarding materials are continually
improved by the network.
• The network begins to take on the tasks associated
with making new members productive

8. These next two areas are where I feel this system concept
differentiates itself from content management systems or
Wiki’s, which are already being used to some degree to
fulfill the first two goals though not in the detail and
volume I envision for this system. This next goal involves
providing a gateway for data and numerical analysis.
Especially in cases where there may be no public gateway
at all. JPL Horizons or the Minor Planet Center’s web
portal have great access, but I can guess that not all
facilities having data relevant to an observation project or
have available computational power have this type of
interface. So a simplified way to provide that should be
beneficial.

9. Provide Computational Support
• Provide a framework in which “manual” computations can be performed,
commonly formatted, aggregated and vetted by the research project’s
network participants.
• Harness the untapped computational powers of the idle desktop or even
an entire idle data center. One method might be Internet scale clustering
through message passing interfaces. Another method would be simply
grabbing a dataset, operating on a dataset, returning a standardized result
set.
• Provide project integration points or gateways to existing systems
containing data that might of use but otherwise have no public interface.
• Achieved partially through simple and standardized application
programming interfaces (API) or domain specific languages (DSL).

10. Graph databases represent an alternate way for a software
system to persist data that uses attributes of data objects to
create connections or paths to other data. It’s widely used by
social networking platforms to connect people but I propose
to use it to expose new connections among research, ideas,
facilities and discoveries. You are exposed to this technology
daily. This technology is currently being used to create a
profile of you based on things like what you typically
purchase and what you search for on the internet. These
attributes are used to predict things like whether a credit
card transaction is fraudulent, or what ads to show you. Its
one of my personal missions to use graph database
technology to a greater degree in scientific research.

11. Harness the Power of the
Network Graph
• This system would have a research project centered focus
instead of an individual person focus as in a social
networking platform.
• Would use graph database technologies to reveal
relationships between research that might have gone
unnoticed with the widely used Wiki approach.
• The content would be massively searchable. Posts even
down to the random “musing” on a subject will start to
generate a collective insight.

12. How would one start to use a
system like this?
We’ll start by identifying some likely users of
this type of system, the “Actors”, and we’ll list
some of their attributes. Then I’ll give two
sample use cases or “user stories”.

13. I like to use a software engineering technique that
involves storyboarding. At a high level this mimics
the same process that scenes from a screenplay are
laid out in a movie to lay out how a user will interact
with this system. So far what I’ve laid out are like
props, locations and action that are available to us
perhaps. Now let’s look at some of the attributes of
a few of the people that might participate in such a
system, they are called actors in this design
methodology. Leveraging graph technology, these
attributes will be how researchers will intersect with
volunteers or other professionals doing similar work
and vice versa.

14. The Actors
• Researcher Needing follow-up or
confirmation
• Researcher needing access to data or
insight on what other similar projects exist.
• Volunteer Observer
• Volunteer Research Assistant

15. A Researcher has a
Profile
• Areas of specialization
• Current projects
• primary focus
• access to facilities
• past publications

16. AVolunteer has a
Profile
• Areas of interest
• Relevant skills
• Availability (commitment level)
• Past history (recommendations perhaps?)
• Relevant equipment

17. Researcher Starts a Project
• The project could descend from parents i.e. Asteroid
Observation Program >> Orbital Certainty Projects >> (new
Project) P-1087-TH Observation.
• Project is tagged with interest areas, skills required,
equipment required etc.
• A list of potential volunteers and researchers materializes to
the researcher as well as similar research projects
• The researcher can begin building a network around this
project.
(An example user story)

18. The project is really the central character.
Examples of a project might be orbital
characterization of a single near earth object,
or the development of a new technique or
observation pattern. Here are some of the
attributes that may create the connection
between projects.

19. The Project
• It’s not exactly an actor but it’s the central focus of
the system.
• It has a subject or series of subjects.
• It has participants.
• It has ever growing content contributions from
simple status posts to detailed calculations and
beyond.
• It has interfaces to necessary systems and data
sources.
• It likely descends from a broader project.
(The Main Character)

20. AVolunteer is Notified
• The P-1087-TH Observation project intersects
this volunteers profile to some degree.
• The volunteer can see the requirements and
similar research projects.
• Volunteer notifies the researcher of an intent to
join the projects network or moves on to the next
notification.
(Another example user story)

21. Where does the story go
from here?
• It’s up to observation professionals to see
merit in this and help me finish the story.
• I have the pieces and parts, need domain
expert input to help identify the integration
points.
• Basically, you, me and a white board.

22. The Pieces and Parts

23. System Life Cycle
• I plan to develop to a minimum level of functionality based on interviews
of active experts, then let community voting drive further development.
• Web based architecture allows for Continuous deployment and
integration.
• Portal exists for defect reports and management.
• Highly available and scalable architecture.
• No ads.
• To keep the system funded I would seek some revenue through directed
integrations, providing infrastructure for funded research and specialized
commercial implementations.

24. Closing
I hope I’ve given you enough of a picture of
what is possible in such a system to generate
some interest. I would be very happy expand
further. In short and staying with the
storyboarding principle I referenced earlier, I
need help from leaders and experts in the
observation field to build the detailed story
points of this system.

25. More Info
• About me –
http://www.linkedin.com/in/jeffmitchell
• Contact me – jeffm@stormbourne.com
• About my company –
http://www.stormbourne.com
• please contact me if you are interested.
ThankYou.