<div dir="ltr">Hi Markus,<div><br></div><div>Sorry for not replying earlier but I wasn't sure what to recommend myself. Thinking back to what we've been doing when parsing such metadata, history shows that you end up implementing a number of heuristics since people are sloppy. So while I might prefer to have the format </div><div><br></div><div><altIdentifier scheme="myscheme">foobar</altIdentifier></div><div><br></div><div>Then I would probably also worry about parsing @scheme to check for things such as case-insensitive matching against a controlled list, matches against a schemeURI. And as far as the identifier itself "foobar": I'd look for the presence of a scheme prefix there, possibly including a URI prefix (particularly for things such as ORCIDs where now users are encouraged to use a URI rather than just the string).</div><div><br></div><div>So my advice is that we should just pick what is simplest at the moment and not worry too much about strict compliance with the way DataCite has gone on this particular issue. Crosswalking these records to DataCite means that a transformation is necessary anyway, and so long as this is easily doable I don't see a big problem.</div><div><br></div><div>-- Alberto</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 9:52 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear collagues,<br>
<br>
In the ongoing series of open VOResource 1.1 points, this is about<br>
the model of altIdentifier, for which we didn't reach a confident<br>
consensus in Trieste.<br>
<br>
In the current draft, altIdentifier is allowed as a child of<br>
vr:Resource itself (where it could house DOIs or, e.g., for VizieR<br>
services that already have them, bibcodes) and of vr:Creator (where<br>
it could house an ORCID)[1]. The content model simply is xs:anyURI.<br>
<br>
So, altIdentifier can contain several sorts of identifiers. The<br>
proposed understanding is that as people start using some identifier<br>
scheme, they will have to agree on a URI form of their identifiers.<br>
<br>
For the identifier types envisioned so far, these are already<br>
defined; for instance, you'd have:<br>
<br>
<altIdentifier>doi:10.21938/<wbr>puTViqDkMGcQZu8LSDZ5Sg</<wbr>altIdentifier><br>
<altIdentifier>bibcode:<wbr>2010yCat.1317....0R</<wbr>altIdentifier><br>
<altIdentifier>orcid:0000-<wbr>0000-0000-000X</altIdentifier><br>
<br>
<br>
I would argue that there's not terribly much that can go wrong there.<br>
However, DataCite models their alternate identifiers differently;<br>
they split off the "identifier literal" from the identifier scheme,<br>
at least in general.<br>
<br>
The three examples above would, for them, look something like this:<br>
<br>
<altIdentifier<br>
scheme="doi">10.21938/<wbr>puTViqDkMGcQZu8LSDZ5Sg</<wbr>altIdentifier><br>
<altIdentifier scheme="bibcode">2010yCat.<wbr>1317....0R</altIdentifier><br>
<altIdentifier scheme="orcid">0000-0000-0000-<wbr>000X</altIdentifier><br>
<br>
I have to say I'm not quite sure why they did it, and I think it's<br>
really a bit dangerous. For instance, I'm not convinced that people<br>
will always leave out the scheme. And if you then have<br>
<br>
<altIdentifier<br>
scheme="doi">doi:10.21938/<wbr>puTViqDkMGcQZu8LSDZ5Sg</<wbr>altIdentifier><br>
<br>
comparisons, perhaps in databases, become painful. Then when<br>
matching against these, you'll have to remember to match both scheme<br>
and literal (also making your queries clumsier). Finally, if you have<br>
actual URLs -- as in IVOIDs, ivo://<a href="http://example.edu/id" rel="noreferrer" target="_blank">example.edu/id</a> --, should this be<br>
<br>
<altIdentifier scheme="ivoid"><a href="http://example.edu/id" rel="noreferrer" target="_blank">example.edu/id</a><<wbr>/altIdentifier><br>
<br>
then? And if it were<br>
<br>
<altIdentifier scheme="ivoid">ivo://<a href="http://example.edu/id" rel="noreferrer" target="_blank">example.<wbr>edu/id</a></altIdentifier><br>
<br>
why bother with the extra attribute?<br>
<br>
Of course, there's the old wisdom to avoid parsing flat strings<br>
whenever possible. In particular for identifiers, I'm finding I've<br>
lost my belief here to some extent. This is partly due to the<br>
experience of IVOA identifiers version 1<br>
(<a href="http://ivoa.net/Documents/IVOAIdentifiers/20070302/index.html" rel="noreferrer" target="_blank">http://ivoa.net/Documents/<wbr>IVOAIdentifiers/20070302/<wbr>index.html</a>),<br>
which defined a "pre-parsed" XML form of IVOIDs. To my knowledge,<br>
this has never been used (except to confuse readers of that<br>
document).<br>
<br>
<br>
Well, after this bit of non-subtle, manipulative suggestion: Does<br>
anyone want to speak up for the DataCite model with an explicit<br>
scheme (or whatever) attribute? Have I perhaps overlooked an<br>
important reason why URI forms will give us headache?<br>
<br>
Cheers,<br>
<br>
Markus<br>
<br>
<br>
<br>
[1] Incidentally: Does anyone want altIdentifier on other elements?<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Dr. Alberto Accomazzi<br>Principal Investigator</div><div>NASA Astrophysics Data System - <a href="http://ads.harvard.edu" target="_blank">http://ads.harvard.edu</a><br>Harvard-Smithsonian Center for Astrophysics - <a href="http://www.cfa.harvard.edu" target="_blank">http://www.cfa.harvard.edu</a><br>60 Garden St, MS 83, Cambridge, MA 02138, USA</div></div></div>
</div>