Metadata for range maps

[DanRosauer]

Today we talked about the format and delivery of metadata to go with range maps. Here are some thoughts to get the ball rolling.

The current range maps are all from IUCN, with a couple of trivial processing steps before upload to MoL. So the metadata is essentially theirs, and most of it applies to the dataset, rather than individual maps.

The MoL metadata doc includes spatial metadata at both the dataset and individual map level, which may be appropriate here.

Of course we can duplicate it all for each species range, if wanted.

My preference at this stage would be to supply metadata as csv table or similar to link to the maps by file name, but open to suggestions.

Dan

[tucotuco]

What do we actually want to do with metadata, aside from augment it with processing information and view it? If nothing more, why not limit data store metadata information to a set of URLs containing the actual metadata?

[eightysteele]

My preference at this stage would be to supply metadata as csv table or similar to link to the maps by file name, but open to suggestions.

Yeah, that could work pretty well. Metadata could be managed and collaborated on in a Google Spreadsheet. A cron job could then programatically export and load it to the datastore.

Another approach might be a YAML metadata file that gets uploaded with each range map shapefile, but managing 10,000 such files might get kind of annoying?

[eightysteele]

What do we actually want to do with metadata, aside from augment it with processing information and view it?

Well, in our high level requirements doc we listed some metadata use cases:

1. Model data inputs are stored as a snapshot
2. Model parameters and software versions are recorded
3. A user can add notes about the record vetting process that should be stored alongside any automatically generated notes from methods contained in the MOL interface (i.e. a tool where a user could say something like ‘Remove all records about 45.00 degrees).
4. Further metadata should be stored (attributions for source data, who ran the models, annotations, user votes, user ids, and tags).

I guess metadata would ideally allow someone to recreate the map? Or allow someone to evaluate quality based on vetting? I also think the user votes and tags are pretty cool and have some potential for useful searching stuff.

If nothing more, why not limit data store metadata information to a set of URLs containing the actual metadata?

Hmmm, not sure I understand what you mean here. Example maybe?

[robgur]

I don't think we should view metadata as means to "recreate the map". Instead, we want to think of it as basically contextual and archival metadata. archival metadata includes fields such as author of the data, the time and date of data creation or assembly, and data ownership and/or custodianship. Contextual metadata would include the purpose for which the data were collected, the standards used in data collection, and tags that indicate how information products derived from the data may be found.

[gaurav]

Is metadata sorted out (for now), with the config.yaml/DBF mapping system? Or is this issue targeting annotations on the map, and we'll have to reconsider this later on?

[tucotuco]

I think that metadata has progressed well beyond the discussions in this thread. Seeking consensus to close the issue.

[tucotuco]

Closing with Dan's approval. ;-)