What Type of Resource Should I Use?

A resource is a published entry in the Minnesota Geospatial Commons. A resource can be GIS data, a web service, an application, a static map, or a combination of these. For more details, see "What is a resource?".

There are two parent types of resources on the MN Geospatial Commons: Data Resources and App Resources. As a publisher you need to decide which category your resource falls into. The primary difference is the associated documentation required. Below is more detail on the two types to help you decide which type is right for your resource.

What is a data resource?

A data resource, or "dataResource" for short, is defined as follows:

A dataResource is a package that contains either file-based and/or service-based data, metadata, and optionally a preview and/or layer file for ArcGIS.
A dataResource will always include MGMG style metadata.
A dataResource may contain multiple file-based data types and/or service types.
A dataResource is registered with the system via a dataResource.xml (see Data Resource Directory Structure for more information).
A dataResource on the Minnesota Geospatial Commons will provide the user with a subset of metadata elements on the main page, a link to the full metadata, links to download file-based data, and connection information for services, as applicable.

What is an application resource?

An application resource, or "appResource" for short, is defined as follows:

An appResource is either a reference to a service, web app/map, or a package containing a standalone application or map product.
An appResource is anything that does not include file-based data.
An appResource does not require MGMG metadata, but has a subset of MGMG elements in its appResource.xml, which is used to create its page on the Commons.
An appResource is registered with the system using an appResource.xml (See help regarding App Resource Directory Structure for more information).
- If there is associated file-based data that is used in a web app or web map, the best way to handle that is with links in the metadata.

Frequently Asked Questions

Q: How do I know which Resource Type to create?

Use the following chart (accompanying text in bullets below):

Decision Tree

Is it an App or Map?
- Fill out appResource.xml
- Is the associated data and/or service also published?
  - Cross Reference data, services and apps in metadata.
Is it a Service?
- Is it a geocoding or geoprocessing service?
  - Fill out appResource.xml
- Is it a spatial data service?
  - Do you wish to publish associated file-based data?
    - Yes
      - Fill out dataResource.xml and write MGMG metadata
    - No
      - Fill out appResource.xml
Is it file-based data?
- Fill out dataResource.xml and write MGMG metadata
- Do you wish to publish an associated spatial data service?
  - Fill out dataResource.xml and write MGMG metadata
  - Remember to register it in your dataResource.xml

Q: What file types can be shared as a dataResource? As an appResource?

See the current list of supported types for more information on the types of resources published on the Commons. If you find your file or application format in that list, then you can publish it on the Commons. Then, use the above decision chart to decide whether or not it should be a data or an application resource.

Q: Why are data services able to be documented as data or app resources?

There are a number of reasons for this overlap, including but not limited to:

Data services are often associated with file-based data that is also available on the Commons. Packaging these resources together allows end users to choose how they wish to use the data. Since the file-based data requires a dataResource.xml, it makes sense to bundle the file-based data together with an associated service, and not require two xml documents.
If they "stand alone" or have multiple data sets within, data services may make sense to be listed as their own application. Also, they are often self-documenting, so the metadata found in the appResource.xml may often be sufficient to judge their suitability for use.