Frequently Asked Questions about the
Field Operations Data Model:
Is this data model proprietary to MapShots?
MapShots is creating the first version as a proprietary implementation. However, when Version 1 is complete,
we intend to place the XML data specification and the COM implementation components into the public domain.
We anticipate that this will occur sometime this summer. We have already spoken with A*E*A about the potential
of placing the model and its implementation into the public domain through one of their working committees.
Return to FAQ
Why the delay placing it in the public domain?
We have been involved with standards efforts that failed in the past because nobody was willing to be the first
to implement the standard. On this effort, we have commitments to our clients that will prevent us from delaying
the implementation until there is a committee consensus approval. We must create something that works for our
current commitments, and then make a formal proposal of the implementation to the industry. This is not unlike
the manner in which the ESRI Shapefile format has become something of a de facto standard. It was a proprietary
implementation that was publicly documented after it met ESRI’s own internal needs.
Between now and the time the model and its implementation
are placed in the public domain, there will be companies that
use our implementation. While we call it a proprietary implementation
at this point, rest assured that anyone that actually uses
the model will have a strong voice in the direction of the
development effort over the next few months.
Return to FAQ
So if these components and data format you are proposing are royalty-free and don’t require a development license, what is the MapShots revenue model for this effort?
The revenue model for this effort is insignificant. We must build these components in order to deliver upon
the commitments that we have made to our current customers. We are incurring additional expenses associated with
the effort of publishing the data model and supporting the components that are adopted by others in the industry,
but we have solicited and received sponsorship for this effort from other companies, so many of these costs are
being offset. The reality is that if we can get the industry to standardize on field operations data exchange
formats, then we (and our competitors) can more quickly get on about our primary businesses. This is the real
revenue model.
And, frankly, as the next question illustrates, this model is really formed from a collection of great thoughts
by other people in the industry. It would be totally inappropriate for us to stake a revenue claim purely on the
basis of the model and its implementation. In all fairness, we must compete in the industry by building good
applications that use this model... not through the develompent of the model itself.
Return to FAQ
And, you thought up this model yourselves?
We wish we could claim it ourselves, but that would be blatantly
untrue. Some of the principals of MapShots have been fortunate
enough to interact with the brightest minds in the industry
over the past several years. These interactions have
come about through our prior employment experiences, participation
on standards committees within groups like A*E*A and CTIC, and
interaction with our customers. The "Infrequently Changing
Data" term and concept was developed within A*E*A discussions.
It was through our work with several John Deere companies
that we matched up the ICD construct to an "Operating Region".
Other people have contributed to concepts such as products
flowing from containers, sensor specifications, and data definition
constructs.
What MapShots did bring to the table is the grunt work of collecting the best
pieces from all of these efforts (with people's permission
and support), and start assembling them into a consistent
data model. We've taken the first cut at the XML data specification,
and we've done all of the COM implementation. The extensibility
model for quickly building Field Operations Device drivers
is also our intellectual contribution.
Return to FAQ
Why do you include an XML data specification as part of the effort?
Most information companies are migrating to XML as the way of representing their data for business-to-business
data exchange. The information companies in agriculture are no exception. XML is a platform-neutral exchange format,
and it is ideally suited to transferring self-describing data. By using XML, we can create components that work
between our own or competitive products installed on the same desktop computer system, local area network, or over
the Internet… all with the same core software components.
Return to FAQ
OK, if XML is so great, why not just create the data specification. Why create a COM implementation, too?
Well, something has to generate the XML, and something has to consume it and translate it into the proprietary
data format implemented internally within an application. While XML is a great data transfer format, creating complex
XML documents, and consuming these same documents can be challenging. Especially for something as complex as we believe
field operations data to be. We use COM architectures extensively in our own development environment, and we have
built COM components to expedite the effort associated with generating and consuming the XML documents. With a little
more effort, we hope to make our components generic enough for other industry participants. And, if our components make
the implementation of the XML data specification a little simpler, then maybe we will get quicker and stronger industry
acceptance of our proposal.
Return to FAQ
Why do you keep saying that field operations data is complex?
We feel that it is imperative to have a single data model that can be used to represent any kind of field
operation data in any level of detail. This means that we have to address a "data" source that is nothing more
than a penciled note in a seed corn notebook within the same architecture that can handle the electronically
logged high-frequency data from an undefined number of sensors. And, while we talk about field
records, how often do you do something homogenous to a whole field? So the record of a single
field operation is often a collage of many separate records.
Return to FAQ
How does your effort relate to other B2B industry standardization efforts?
We are casually aware of other efforts to standardize business-to-business
financial transactions. At this point, we are not aware that
any of those efforts are related to detailed crop production
data. As such, we reference the use of products in our
model, but we have purposely avoided expending any energy
on creating a "product" definition. We hope that these
other standardization organizations join with us to create
a single exchange environment which embraces both financial
and production data interoperability.
Return to FAQ
What do you consider the difference to be between financial and production data?
Financial data is related to inventory transfer, invoicing, etc. Production data is information related
to the agronomy of the field operation. We consider total quantity consumed in a field (and especially the
associated pricing) to be financial. However, the "Lbs/Acre" value to be production. Macy (the founder of
MapShots) continually berates us to consider "does it affect how fast the stalk of corn grows?"
If so, it is production. If not, it is financial. "Ya gotta draw the line somewhere."
Return to FAQ
How does your FOViewer project fit into this effort?
The FOViewer is a MapShots proprietary implementation of a client that uses (and exercises) the field
operations data components that we are proposing. This viewer serves as a way for us to demonstrate the
capability of the underlying data model and the operation of the components. It kind of serves the purpose
of certifying the implementation of anyone else’s device drivers or XML data representation. While we make
the FOViewer available as a free tool to anyone that wants it, it also serves as an integral part of the
products that we deliver to our customers and it is NOT being placed into the public domain.
Return to FAQ
Are there any MapShots dependencies for these components?
No. We have carefully separated our standard user interface and core data components from the FODM
implementation. In its initial release, the components are a combination of VB6 and C++ ATL. As such,
there are dependencies upon VB6 runtimes. Before we make the components available in the public domain,
all VB6 code will be converted to C++ ATL as well.
Return to FAQ
Are there any other third-party dependencies, such as a GIS engine?
The current implementation does have a dependency upon a third-party royalty-free
XML parser. The goal is that the public domain
implementation will offer a way to avoid this third-party
requirement, should the developer of the client applications
wish to implement an XML parser of their own choice.
Return to FAQ
What is the status of your effort today?
We are using the initial implementation of this model in
our current product releases. This includes our own EASi Map
application and the products that we have created for Pioneer
Hi-Bred and John Deere in Europe. During February, we will
be making this initial implementation available to other companies
that want to learn more about the model and its appropriateness
for their application. Our February release will not be fully
implemented, but we commit that the remaining work on the
model will be completed in a manner that preserves compatibility,
or that we will introduce the changes into an updated version
that can coexist with the original implementation. Our February
release will be stable for accessing some of the most common
data formats, including AgLeader, and a company should feel
comfortable in releasing products based upon this pending
release.
Return to FAQ
Do you provide training and support on your components?
Yes, we do. If you monitor our Field Operations Data Model Web Site, you will be able
to stay current with any planned workshops that we will host. The first workshop is scheduled for early spring in 2001.
Attendees at these workshops are only expected to cover their travel, lodging, food, and potentially, facility expenses
(training room rental, etc). These workshops will never be a revenue source for MapShots as long as MapShots is the host.
Return to FAQ
Does your model support sending information to a field device?
We believe that the model must ultimately support sending setup information
and/or work orders to a field device. As of this writing though
(January 2001), this capability is nothing more than a gleam
in our eye. Frankly, we hope to solicit significant
input from other companies that want to participate in the
development and use of this model. We have no strong
preconception of how this functionality should be implemented.
Return to FAQ
How do we stay informed of this effort?
Keep monitoring our Field Operations Data Model Web Site. We will continue to post new
information, links to product downloads, etc. You will also find a discussion forum dedicated exclusively to the
discussion of field operations. The forum is open to questions and comments about the technical implementation of
the components or non-technical discussion about the nature of field operations data.
Return to FAQ
|
