[Esip-documentation] ACDD globals: creator

[Nan Galbraith]

Hi All -

I'm getting some push back on the 'creator' terms from the OceanSITES
data management team. Do others think this term is too easily misconstrued?

Creation_date is usually used in relation to files, not conceptual data sets
or projects; is it a mistake to use 'creator' for  a person responsible for
'collecting the data' and/or 'planning the experiment' and not the 
person who
simply created the file?

The ISO terms, which Ted sent out on May 6, seem to offer some more 
appropriate
choices. If we're going to make it mandatory that one or more people 
associated
with a data set are identified, should we decide who they are, and then 
pick the
most appropriate term for each? Would it be possible to recommend that ONE
of owner, rightsHolder, or principalInvestigator be used to identify the 
person we
now call 'creator' ?

IMHO, we need to provide 2 contacts;  the science person 
(owner/PI/rightsHolder) and
the technical information person (publisher, resourceProvider, processor).

Thanks for any thoughts on this.
- Nan


**

	

*Concept name (English)*

	

*Code*

	

*Definition*

1.

	

CI_RoleCode

	

	

function performed by the responsible party

2.

	

resourceProvider

	

resourceProvider

	

party that supplies the resource

3.

	

custodian

	

custodian

	

party that accepts accountability and responsibility for the resource 
and ensures appropriate care and maintenance of the resource

4.

	

owner

	

owner

	

party that owns the resource

5.

	

user

	

user

	

party who uses the resource

6.

	

distributor

	

distributor

	

party who distributes the resource

7.

	

originator

	

originator

	

party who created the resource

8.

	

pointOfContact

	

pointOfContact

	

party who can be contacted for acquiring knowledge about or acquisition 
of the resource

9.

	

principalInvestigator

	

principalInvestigator

	

key party responsible for gathering information and conducting research

10.

	

processor

	

processor

	

party who has processed the data in a manner such that the resource has 
been modified

11.

	

publisher

	

publisher

	

party who published the resource

12.

	

author

	

author

	

party who authored the resource

13.

	

sponsor

	

sponsor

	

party who speaks for the resource

14.

	

coAuthor

	

coAuthor

	

party who jointly authors the resource

15.

	

collaborator

	

collaborator

	

party who assists with the generation of the resource other than the 
principal investigator

16.

	

editor

	

editor

	

party who reviewed or modified the resource to improve the content

17.

	

mediator

	

mediator

	

a class of entity that mediates access to the resource and for whom the 
resource is intended or useful

18.

	

rightsHolder

	

rightsHolder

	

party owning or managing rights over the resource

19.

	

contributor

	

contributor

	

party contributing to the resource

20.

	

funder

	

funder

	

party providing monetary support for the resource

21.

	

stakeholder

	

stakeholder

	

party who has an interest in the resource or the use of the resource


>
>> wonder if we could go with the (slightly less symmetrical) terms 
>> creator_name, creator_info, creator_institution, 
>> creator_institution_info - which assumes that an 'unmodified' creator 
>> is by default a person.
>
> No objection, please consider 'creator_institution_name' as the third 
> one, so as to be parallel.
>
> The rest of your questions are good, and I don't have an 
> opinion/answer on them at this point. I think any direction the group 
> chooses could be suitable.
>
> John
>
>
>>
>> How should the '_info' information be presented in an ISO 19139 
>> compliant way? Can we
>> just choose some fields within CI_ResponsibleParty and list those, or 
>> are we thinking
>> of an xml snippet for this attribute?  An example (from OGC) could be 
>> coded either as:
>>
>> creator_info: 'organisationName:con terra GmbH, 
>> email:voges at conterra.de' ;
>>
>> or as:
>>
>> creator_info: '<contact>
>>              <CI_ResponsibleParty>
>>                 <individualName>
>>                    <gco:CharacterString>Uwe Voges</gco:CharacterString>
>>                 </individualName>
>>                 <organisationName>
>>                    <gco:CharacterString>con terra 
>> GmbH</gco:CharacterString>
>>                 </organisationName>
>>                 <contactInfo>
>>                    <CI_Contact>
>>                       <address>
>>                         <CI_Address>
>>                            <electronicMailAddress>
>>                              
>> <gco:CharacterString>voges at conterra.de</gco:CharacterString>
>> </electronicMailAddress>
>>                         </CI_Address>
>>                      </address>
>>                   </CI_Contact>
>>                 </contactInfo>
>>             </CI_ResponsibleParty>
>>         </contact>' ;
>>
>> Do we recommend one over the other?  Will a multi-line, verbose 
>> attribute like the
>> latter be hard for users to implement? Does it add any functionality?
>>
>> Thanks again -
>>
>> Nan
>>
>>
>


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


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