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

Mon Sep 29 15:31:43 EDT 2014

Hi all -

I'm voting for some combination of 2 & 3: pick and choose which
names to  change, and make any changed names into aliases.  We
can try to minimize the changes, but still clean things up and force
clearer definitions. Anyone who wants to stick with the older version is
free to do so, but the buy-in to v1.3 should be worth the effort.

I've looked at the matrix of changes and can easily see going back
to creator_name and publisher_name - I think creator and publisher
were introduced when someone wanted this to be a compound field
that included email, URL, etc. To me it's a no-brainer to roll those back.

I'd also be happy to return to date_created, which is at least as meaningful
as date_product_modified - the latter doesn't mean anything, at least to me,
for obs data.

I prefer URLs to URIs, and since that's how we started, I vote for sticking
with it unless someone can explain why it needs to change.

For institution and project, can't we alias these to creator_institution and
creator_project, and let folks choose how specific they want to be? In my
case, the new terms protect the people and projects who are collecting and
sharing the data.

The new (?) contributor_info field has me mystified - I don't recall any 
discussion
about this and it seems too far from the structure of the rest of the 
contacts.

Cheers - Nan

On 9/29/14 12:18 PM, Bob Simons - NOAA Federal via Esip-documentation 
wrote:
> 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
>>
>>

-- 
*******************************************************
* Nan Galbraith                        (508) 289-2444 *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                                *
*******************************************************

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