[eml-dev] givenName element uses

[inigo]

it is good to know how the EML has evolved to address the multiple ways 
that humankind use to refer to an individual, thanks for the insight.

Just to make my intentions clear, i think EML addresses this issue much 
better than FGDC and its flavors (BDP, ESRI, etc), and the same goes for 
the Dublin+Darwin core specs.

One issue arises when moving metadata from EML to a relational database 
which has "middlename" as information placeholder. In most of the cases, 
the "order" rule may succeed,
and the first name may go well in the first name, and the next 
"givenName" content, if existent, may go well into the "middlename".  
But for example, poor Juan Luis will loose his Mercedes in the process.
so should it be Juan Luis all a  "first Name" (nombre propio) or should 
it be all Juan Luis Mercedes? Probably not even John can tell, as at 
best, some will equate the latin concept of the "nombre de pila" to the 
north american concept of "middlename".  In cases, parts of the compound 
(dash-separated sometimes) lastname lands as middlename.  Ive seen all 
sort of crazy mappings. I have no idea on the Asian structures and 
constructs, but I can imagine that the crippling of their natives names 
and identifier structures is substantial during the adoption of the 
US-centric system.  Then I digress...

The problem is there, noted, a middlename, or distinct placeholder is no 
holy grail.  But at least in my view, it addresses an 80% (to give Colin 
Powell favorite number) of the ambiguity problems we may encounter, as 
it gives an opportunity to the metadata entry person to make it right 
for the rest of us who don't really know the Jose Luises of the world.   
As a plus, I would be open to add a nick name field, an other colorful 
constructs that are necessary in those unfamiliar instances.

 cheers, inigo

Matt Jones wrote:
> Hi Inigo,
>
> We started out with:
>   (givenName?,middleName?,surName)
> as the model for earlier versions of EML.  Some people complained that this
> does not accomodate people who wish to represent multiple family names in
> some languages, for example "Juan Luis Mercedes Gomez".  So we generalized
> the model to:
>   (givenName?,middleName*,surName)
> Then people were confused about whether any particular sequence of names
> should go in multiple middleName elements or in one givenName and one
> middleName element. Someone challenged us to define the difference between
> givenName and middleName elements.  We decided that there wasn't any
> difference, and that really one or more middle names were simply more
> givenNames.  So we ended up with the model:
>   (givenName*, surName)
>
> where the first givenName would be someone's first name, the second
> givenName would be their middleName, and third and subsequent givenName
> elements would be additional middle or family names. The only reason we
> wanted to differentiate the components of the name at all was so that
> automated parsers could translate EML documents into other standards that
> used this level of granualrity and so that automated processors could
> properly convert names into abbreviated versions of the name for e.g.,
> bibliographic citations that want only initials for given names.  For that
> we needed to differentiate the surName from all of the other names, and
> tokenize all of the  names.
>
> Could you explain the problems you are having with this model in terms of
> matching subjects and migration to DBs so that we can figure out if there
> are automated processing tasks that the current model does not address?
>
> Thanks,
> Matt
>
> On Thu, Sep 18, 2008 at 4:49 PM, inigo san gil <isangil at lternet.edu> wrote:
>
>   
>> for the sake of proper granularity, and in an attempt to disambiguate the
>> interpretation of the contents of <givenName>, would eml-dev consider
>> reducing the cardinality of the element to 0 to 1, and adding a middleName
>> optional element?  of course, if middleName sounds to straightforward you
>> can use some other semantical contortion to refer to such concept - say
>> saddleName :)
>>
>> the ambiguity causes trouble when matching subjects, migration to DBs, etc.
>> inigo
>> _______________________________________________
>> Eml-dev mailing list
>> Eml-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>
>>     
>
>
>
>