[Esip-documentation] proposal to move forward re changed names

[John Graybeal via Esip-documentation]

Your input requested below

Hi everyone,

Given the responses about changed names, I reviewed all the changed names (and the historical record on the v1.2.3 Working-Discussion page), and I compared all the attributes and definitions in this table:
  https://docs.google.com/spreadsheets/d/19fl5AgGkckG03yTchUjYUp4YnR09Fn1Nqps2KHenkC4/edit#gid=849563469
I've also put a list of the changed or dropped names at the end of this email. There were 11 names changed, and 2 dropped.

The case has been forcefully made that none of the existing names should be changed. I see 4 ways forward; options 3 and 4 preserve the availability of all the original names, but with different emphasis.
1) Leave the changes as they've been made to date
2) Pick and choose which names to leave changed, and which to revert, on case by case basis
3) Make all the changed names into aliases to agreed new ones, so that original names remain supported and documented
4) Revert to the original names, clarifying the definitions where agreement is possible, and then add new names as needed

To confirm approaches 3/4 will work, I documented below the resulting relations for Option (3). If Option (4) is preferred, then 'aliased to' in that list is replaced by 'takes definition (if agreed) of'. Both of these options seemed workable.

To keep us moving, I request that interested parties quickly respond to the above options, by ranking each one as "Best, Good, Tolerable, Unacceptable". You can respond in a survey on the third sheet of the Google spreadsheet:
  https://docs.google.com/spreadsheets/d/19fl5AgGkckG03yTchUjYUp4YnR09Fn1Nqps2KHenkC4/edit#gid=74138036
or to this list if you'd rather, and I'll add to the survey.  Anonymous responses are OK by me.

The results of the survey can inform the email discussion and the Adjudication meeting on Thursday. 

John


=== Relations resulting for Option (3) ===
-------------------------------------------------------
date_created aliased to date_product_originally_created ('date on which this product was originally created'; a new attribute)
date_modified aliased to date_product_modified
  new attribute: date_values_modified
date_issued aliased to date_product_available
creator_name aliased to creator
creator_url aliased to creator_uri
institution aliased to creator_institution
project aliased to creator_project
publisher_name aliased to publisher
publisher_url aliased to publisher_uri
contributor_name aliased to contributor_info

I'm not sure anyone is concerned about the next two, but if they are, then:
Metadata_Link (originally in intro text only) aliased to  metadata_link
standard_name_vocabulary needs no alias, it is preserved as is.

=== List of Changed or Dropped attribute names ===

date_created -> DROPPED or replaced by date_product_modified, date_values_modified  (depending on your initial def'n)
date_modified -> date_product_modified, date_values_modified
date_issued -> date_product_available

creator_name -> creator
creator_url -> creator_uri    (the second one has an 'i' at the end, to allow any type of uniform identifier)
institution -> creator_institution
project -> creator_project
publisher_name -> publisher
publisher_url -> publisher_uri  (same change as for creator_url/uri)
contributor_name -> contributor_info  

Metadata_Link (in text only) -> metadata_link
standard_name_vocabulary -> DROPPED

=== List of Added attributes ===

Based on public and private messages, I don't think there is any significant concern about the following new attributes (all are Suggested):
creator_institution_info
creator_project_info
publisher_institution
publisher_institution_info
publisher_project
publisher_project_info

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20140928/66d80981/attachment.html>