[eml-dev] Storing an ORCID in EML

Margaret O'Brien margaret.obrien at ucsb.edu
Mon Jul 14 17:12:42 PDT 2014 

Well, now I'm more confused.
in a URI, "http" is a recognized uri-scheme, so part of the name. But in 
reality, it's very confusing.

I looked around for recommendations from the DOI-org for how they want 
to be referred to (thinking they might say to use a namespace, as in 
"urn:doi").  They aren't an officially registered URN. See this page: 
http://www.doi.org/factsheets/DOIIdentifierSpecs.html. They talk about 
URI/URN/URL about one-third down the page.

So maybe a URI with a location-based scheme (like http) is OK? I was 
hoping to not have to look up the approved URN for every identifier I'd 
like to use, but at the same time, not add to confusion by implying a 
web location.

M






-----------
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER
Marine Science Institute, UCSB
Santa Barbara, CA 93106
805-893-2071 (voice)
http://sbc.lternet.edu

On 7/14/14 4:06 PM, Margaret O'Brien wrote:
> Matt and Kyle -
>
> OK, no codes. But the the protocol should not be included -- because 
> that's the part that makes the URI into a URL, and the system could 
> change the protocol they use.
>
> For example, right now, this works: "http://doi.org", but 
> "https://doi.org" does not. We don't know what they will do in the 
> future, or what other protocols might appear.
>
> so how's this:
> <alternateIdentifier 
> system="doi.org">TEST_TEST_TEST_TEST</alternateIdentifier>
>
> or with Kyle's example:
> <userId directory="orcid.org">0000-0003-1095-6607</userId>
>
>
> Margaret
>
> -----------
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER
> Marine Science Institute, UCSB
> Santa Barbara, CA 93106
> 805-893-2071 (voice)
> http://sbc.lternet.edu
>
> On 6/27/14 8:15 PM, Matt Jones wrote:
>> Kyle and Margaret --
>> I agree with Margaret that you should use the userId field -- that is 
>> exactly what we created it for.  And I will be very excited to see it 
>> used, as having an ORCID would be a tremendous help in providing 
>> users with list of their data -- the Creator field can be ambiguous.
>>
>> My only caveat is that I don't think you should use a bare word as 
>> Margaret suggested for the directory -- I think its better to use the 
>> URI for orcid as you originally proposed.  So, I think this would be 
>> best:
>>
>> <userId directory="http://orcid.org/">0000-0003-1095-6607</userId>
>>
>> I am hoping that we will being indexing content against people's 
>> ORCIDs in the KNB and DataONE soon -- it would be a great help if EML 
>> providers started inserting this field.
>>
>> Matt
>>
>>
>>
>> On Fri, Jun 27, 2014 at 1:30 PM, Kyle Braak [GBIF] <kbraak at gbif.org 
>> <mailto:kbraak at gbif.org>> wrote:
>>
>>     Dear Margaret,
>>
>>     Thank you for your quick response and detailed explanation. It's
>>     just the answer I was hoping for.
>>
>>     Your guidance is greatly appreciated,
>>
>>     Kyle
>>
>>     On Jun 27, 2014, at 6:48 PM, Margaret O'Brien wrote:
>>
>>     > Hi Kyle -
>>     > I've used the userId element for this sort of thing. Since it's
>>     repeatable, a party can have identities in several systems.
>>     >
>>     > I think the userId element is a better choice than using the id
>>     attribute on the creator|contact, etc element, too. For 2 reasons:
>>     first, the id attribute is used as an internal link in the EML doc
>>     itself. If we use it for other purposes, it could become
>>     overburdened. Second, as an attribute, there can be only one id
>>     (for an element). It's not likely that a person has only one 'id'
>>     (whereas <userId> is repeatable.)
>>     >
>>     > I have one other suggestion. I wouldn't put the url into the
>>     directory element. Instead, I'd say this:
>>     >> <userIddirectory="orcid">0000-0003-1095-6607</userId>
>>     > and let the program consuming the EML decide what to do with it
>>     (eg, transform to a url). Presumably there could be many ways to
>>     handle that content. As an analogy, I use a similar element,
>>     <alternateIdentifier>, for citations. Here are some examples of
>>     how they look:
>>     >
>>     > <alternateIdentifier
>> system="isbn">978-90-481-3931-6</alternateIdentifier>
>>     > <alternateIdentifier
>> system="doi">10.1007/978-90-481-3931-6</alternateIdentifier>
>>     > <alternateIdentifier
>> system="sbclter-bibliography">1003</alternateIdentifier>
>>     >
>>     > By using just a string for the system="" (or for the
>>     directory="", in the case of the <userId>), it doesn't matter
>>     whether the content is a formal system like DOI or ISBN, or one
>>     that only a few people know about (sbclter-biblio). They all get
>>     handled the same way.
>>     >
>>     > But others in eml-dev may have a different opinion on that.
>>     >
>>     > Margaret
>>     >
>>     >
>>     > -----------
>>     > Margaret O'Brien
>>     > Information Management
>>     > Santa Barbara Coastal LTER
>>     > Marine Science Institute, UCSB
>>     > Santa Barbara, CA 93106
>>     > 805-893-2071 (voice)
>>     > http://sbc.lternet.edu
>>     >
>>     > On 6/27/14 7:13 AM, Kyle Braak [GBIF] wrote:
>>     >> Hi eml-dev list,
>>     >>
>>     >> I'm trying to figure out what the best practice is for storing
>>     a party's ORCID, which represents a unique researcher identifier.
>>     Here is a random ORCID as an example:
>>     http://orcid.org/0000-0003-1095-6607
>>     >>
>>     >> The most obvious choice would be to use element "userId"[1] ,
>>     specifying http://orcid.org as the personnel directory:
>>     >>
>>     >> <userIddirectory="http://orcid.org/">0000-0003-1095-6607</userId>
>>     >>
>>     >> Alternatively, it should also be possible to use attribute
>>     "id"[2], specifying http://orcid.org as the data management system:
>>     >>
>>     >>
>> <contactid="0000-0003-1095-6607"system="http://orcid.org/"scope="system">
>>     >>
>>     >> I have tried searching KNB for sample documents containing the
>>     "userID" element but couldn't find any.
>>     >>
>>     >> Your guidance will be greatly appreciated.
>>     >>
>>     >> Thanks,
>>     >>
>>     >> Kyle Braak
>>     >> Developer
>>     >> Secretariat of the Global Biodiversity Information Facility 
>> (GBIF)
>>     >> Universitetsparken 15, DK-2100 Copenhagen Ø
>>     >> Denmark, Europe
>>     >> www.gbif.org <http://www.gbif.org> <http://www.gbif.org/>
>>     >>
>>     >> [1]
>> https://knb.ecoinformatics.org/#external//emlparser/docs/eml-2.1.1/./eml-party.html#userId
>>     >> [2]
>> https://nis.lternet.edu/nis/schemas/eml/lter-project-eml-2.1.0/docs/eml-resource.html#SystemType
>>     >>
>>     >>
>>     >>
>>     >>
>>     >>
>>     >> _______________________________________________
>>     >> Eml-dev mailing list
>>     >> Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org>
>>     >> 
>> http://lists.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>     >
>>     >
>>
>>     _______________________________________________
>>     Eml-dev mailing list
>>     Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org>
>> http://lists.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>
>>
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://lists.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev

More information about the Eml-dev mailing list