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

[Bob Simons - NOAA Federal via Esip-documentation]

You can probably guess, I think only option 4 is good.
1 is intolerable.
2 would be okay if someone convinced me that an old name is intolerable 
and a new name is better. No one has yet.
3 is intolerable because it leads to a mess. (People are more likely to 
use small and easy-to-understand standards.)
4 is good.

Note that if #4 is accepted, some of the new definitions shouldn't be 
applied to the original terms.
Notably, the definitions for the URI terms *mustn't* be applied to the 
URL terms.
Those changes were a bad idea anyway because the purpose of a URI vs a 
URL is different.
The purpose of a URI is to identify a resource, often uniquely, even if 
the URI doesn't point to the actual resource.
The purpose of a URL is to point to a resource (e.g., information about 
a creator/the project/the dataset). ERDDAP, for example, wants URLs (not 
URIs) so that it can know that it should show users an HTML link to it.
If you want to add new URI terms (leaving the URL terms intact), go 
ahead. But define a different purpose for them vs. the URL: a way to 
provide a unique identifier for the publisher|creator|... .  (Which is 
more like a URN, but perhaps you don't want to restrict usage to URNs.)


On 2014-09-28 10:26 PM, John Graybeal via Esip-documentation wrote:
> *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 
> <http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_1-2_Working>), 
> 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
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

-- 
Sincerely,

Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St, Suite 255A
Monterey, CA 93940
Phone: (831)333-9878 (Changed 2014-08-20)
Fax: (831)648-8440
Email: bob.simons at noaa.gov

The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric
Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <>< <><

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