[Esip-documentation] ACDD globals: creator
John Graybeal
graybeal at marinemetadata.org
Thu Jun 6 16:31:26 EDT 2013
I don't know the 'right' answer for the OceanSITES community; I have a few thoughts for data from diverse communities.
I like your approach of collecting ISO roles to satisfy needs. There are a lot of overlapping roles in the RoleCode list, and the definitions are almost entirely content-free (haven't these people read dictionaries?), so a universal solution is impossible.
The 'need' I associate with the "data creator" role is to find someone I can ask (in my role as a user or data maintainer) "what made this data set what it is?" Someone who is owner, rightsHolder, or principalInvestigator may be able to answer some of those questions; but I bet the role that can answer most of them is originator, because he/she understood enough to create the final product.
The second need I have is to answer "what is up with my access to this data?" These include technical format and content queries, access issues, organization of repository' issues, and rights issues. I tend to associate most of that knowledge with the publisher role. Though I have no idea what the difference is between ISO roles of resourceProvider, distributor, and publisher.
In my world, the "science person" may not handle any of the functions you put in parentheses, because the data may or may not have been produced by a scientist, and a related scientist may or may not be an owner or a PI or a rightsHolder. These functions may not exist for the data, or may be satisfied by non-scientists.
Speaking of which, I notice the key word in ISO definitions is always 'party', which nicely dodges whether it has to be a person or not. I assume not.
I think our approaches are similar, just some of the details very. See if anything resonates for you.
John
P.S. In case it helps: I am considering a general set of info, but not advocating it for OceanSITES. Based on the fact it's all but impossible to pull forward names for more than one or two roles, I decided to have just 1 required contact person (or agent), let's call that the PointOfContact role. Then I can add other roles to that person too. I also require various institutional roles and relations. I will provide various attributes for the PointOfContact field, for example using ISO19139 XML within a text field; and I could even put multiple contacts in a collection, if I want. That all works if you don't have to teach everyone how to do it….
My system at the moment: There is a publisher institution and project; a creator institution and project; and a primary contact info. These are all required, and the primary contact info can have one of the ISO roles (in addition to primary contact) if someone wants. Then there is a Creator Individual, required if such an individual exists (as opposed to an automatically generated data set). And finally, Owner Institution, Owner Project, and Owner Individual, if someone wants to provide that.
On Jun 6, 2013, at 12:20, Nan Galbraith <ngalbraith at whoi.edu> wrote:
> 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 *
> *******************************************************
>
>
---------------
John Graybeal
Marine Metadata Interoperability Project: http://marinemetadata.org
graybeal at marinemetadata.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20130606/8b95c65f/attachment-0001.html>
More information about the Esip-documentation
mailing list