As a user I want to see alternative identifiers for datasets so that I can access other available information related to those datasets.
10037
Reporter: omeyn
Assignee: kbraak
Type: Feedback
Summary: As a user I want to see alternative identifiers for datasets so that I can access other available information related to those datasets.
Description: eg the BCI holds descriptive info about collections, so links to their pages should be made available through the alternative identifiers accessible from dataset/id
Priority: Major
Resolution: Fixed
Status: Closed
Created: 2011-10-27 12:16:21.984
Updated: 2013-08-29 14:46:03.167
Resolved: 2012-12-03 18:51:53.135
Author: kbraak@gbif.org
Created: 2012-01-17 16:06:50.533
Updated: 2012-01-17 16:06:50.533
See the attached screenshot for how alternative identifiers are currently displayed in the right hand sidebar of the dataset page.
A raw identifier only has a string URL, and this is long and obviously won't be the prettiest thing to display.
If the identifier has a type (like we know it's a GBIF Portal url, we can only display the type instead of the whole long URL).
Perhaps in the absence of a type, however, we should truncate the long string to 15 characters or something, what do you think?
Author: mdoering@gbif.org
Created: 2012-01-17 21:05:55.605
Updated: 2012-01-17 21:05:55.605
Yes, lets truncate it. There is a free marker macro already for this used on the species page.
Before truncating though Id vote for showing "typed" links as you say.
- if its a doi, lets display the dpi only and not the http link.
- if its a URL, show the domain only? For example data.gbif.org, eol.org, etc.
- if its an LSID, show the lsid, but link with a resolver
There is an Identifier class in the CLB api already that does most of this.
Maybe its worthwhile sharing this class in a common api project?
Author: kbraak@gbif.org
Created: 2012-01-18 10:27:32.925
Updated: 2012-01-18 10:27:32.925
Sounds much cleaner the way you propose.
Yes, +1 for moving this class to a common project.
Nonetheless, I will apply the truncating macro.
Author: kbraak@gbif.org
Created: 2012-01-18 15:52:20.908
Updated: 2012-01-18 15:52:20.908
The Registry's Identifier class now uses the IdentifierType from gbif-common-api for its type field. Changes to metadata-service and service mean that the type should always be filled now for the Identifier, defaulting to IdentifierType.UNKNOWN.
In the Portal Dataset page, I followed the layout suggestions you listed, but I treat URLs as LSIDs, short of knowing an easy way to only display the domain.
Author: kbraak@gbif.org
Comment: New screenshot added showing how the alt. identifiers are displayed following latest changes.
Created: 2012-01-19 12:35:37.015
Updated: 2012-01-19 12:35:37.015
Author: mdoering@gbif.org
Created: 2012-01-19 12:49:31.724
Updated: 2012-01-19 12:49:31.724
I think we should show the DOI or LSID, not just the "type" as there could be multiple ones for the same type.
For example:
Author: mdoering@gbif.org
Comment: the clb Identifier.getIdentifierLink() does some of that work, worthwhile sharing as a common utility maybe?
Created: 2012-01-19 12:50:48.206
Updated: 2012-01-19 12:50:48.206
Author: kbraak@gbif.org
Created: 2012-01-19 14:12:25.818
Updated: 2012-01-19 14:12:25.818
Agreed, we should try to resolve it to a link. Yea, I suppose there could be multiple so this makes perfect sense.
Would it be suitable to move this to gbif-common-api's IdentifierType (it is the link based on the type after all)?
Author: kbraak@gbif.org
Created: 2012-10-26 16:18:53.507
Updated: 2012-10-26 16:24:34.849
So to recap,
we still want to better display alternate identifiers.
There is a method called getIdentifierLink() in https://code.google.com/p/gbif-common-resources/source/browse/gbif-api/trunk/src/main/java/org/gbif/api/model/checklistbank/Identifier.java that could help do this. Actually, the same method exists in the common identifier class also: https://code.google.com/p/gbif-common-resources/source/browse/gbif-api/trunk/src/main/java/org/gbif/api/model/common/Identifier.java
For now, however, the Dataset's identifier ( https://code.google.com/p/gbif-common-resources/source/browse/gbif-api/trunk/src/main/java/org/gbif/api/model/registry/Identifier.java ) can't make use of this method.
The proposition is, to move getIdentifierLink() out to a common utility class. Furthermore, do we really need all 3 separate unrelated types of identifier classes in our API? They all share at least an IdentifierType, and String identifier:
Registry Identifier
private Long id;
private IdentifierType type;
private String identifier;
private UUID networkEntityKey;
Checklistbank Identifier extends NameUsageComponent
private String identifier;
private String title;
private IdentifierType type;
private Integer key;
private Integer usageKey;
private UUID datasetKey;
Common Identifier has
private Integer entityKey;
private String identifier;
private String title;
private IdentifierType type;
Author: mdoering@gbif.org
Created: 2012-10-29 10:13:01.765
Updated: 2012-10-29 10:13:01.765
Indeed this is an open issue in our common API. Having 3 different Identifier classes which are almost the same isnt good.
See also http://dev.gbif.org/issues/browse/GBIFCOM-24 when we started a new identifier interface for the common 2 properties.
Do we need a new common api issue for a refactoring?
Author: mdoering@gbif.org
Created: 2012-10-29 10:15:26.448
Updated: 2012-10-29 10:15:26.448
The common identifier seems to contain the shared fields, with entityKey being the entity the id is attached to, usageKey in the clb class and networkEntityKey in the dataset version.
Author: kbraak@gbif.org
Comment: Until we resolve how the 3 Identifier classes in our common api relate to one another, further work on this issue is halted. I have added the blocking issue GBIFCOM-24 now, instead of creating a new one.
Created: 2012-11-02 16:41:09.682
Updated: 2012-11-02 16:41:42.208
Author: mdoering@gbif.org
Created: 2012-11-02 18:17:24.388
Updated: 2012-11-02 18:17:24.388
Well, then we need to work on the blocking api issue. GBIFCOM-24 should also be updated cause its content does not fit the current situation - there is no interface anymore.
It should rather be about unifying the 3 classes by whatever means, e.g. introducing the interface back again, having a shared base class or use a singel common class. Whatever we think fits best.
Author: mdoering@gbif.org
Comment: Maybe we should better create a new common issue for this and close the 24 one as wont resolve or invalid
Created: 2012-11-02 18:18:14.761
Updated: 2012-11-02 18:18:14.761
Author: kbraak@gbif.org
Comment: We can now use getIdentifierLink() from Dataset, as a result of latest change https://code.google.com/p/gbif-common-resources/source/detail?r=1193
Created: 2012-11-15 17:27:15.939
Updated: 2012-11-15 17:27:15.939
Author: kbraak@gbif.org
Created: 2012-11-16 14:51:22.85
Updated: 2012-11-16 14:51:22.85
[~mdoering@gbif.org] [~jcuadra@gbif.org] Guys, when displaying identifiers on the dataset page, I think it is always valuable to display the type if it exists.
There isn't much room though in the right sidebar.
So, the question is:
Which of the two screenshots do you like better?
-The 1st one, that always shows the type
-The 2nd one, that just shows the link.
Author: jcuadra@gbif.org
Created: 2012-11-16 14:58:22.983
Updated: 2012-11-16 14:58:44.124
I like when displaying the Identifier type:
Just my opinion, but I would display the type name in a font similar to the "Google Fusion Tables UTF 8" font on http://dev.gbif.org/issues/secure/attachment/11417/Screen%20Shot%202012-11-16%20at%202.44.52%20PM.png
and besides (or below), the identifier per se.
Author: mdoering@gbif.org
Created: 2012-11-16 15:15:11.672
Updated: 2012-11-16 15:15:11.672
Hm, tough call. As you say there is little space so joses idea seesm reasonable to use a second row.
I would also rather show the identifier alone and not the generated link. Btw, where does UUID and GBIF Portal ID come from? they should really show the actual id, otherwise its a bit pointless.
Author: kbraak@gbif.org
Created: 2012-11-16 15:18:42.076
Updated: 2012-11-16 15:18:42.076
Thanks for the comments Markus and Jose. This screenshot shows a revised version, with the type underneath, just like the Google Fusion Table case.
In this example, the Portal ID and UUID are shown with the link underneath. At least the Portal ID comes from the Registry's identifier table.
Author: mdoering@gbif.org
Comment: a bit confusing, it needs more spacing so you know if its underneath or the title of the next id. Probably needed also for the data links below
Created: 2012-11-16 15:31:49.146
Updated: 2012-11-16 15:31:49.146
Author: kbraak@gbif.org
Comment: Screenshot shows another version, with more spacing for identifiers and data descriptions below. Please take a look. Thanks
Created: 2012-11-16 15:50:27.151
Updated: 2012-11-16 15:50:27.151
Author: mdoering@gbif.org
Comment: It feels the identifier type is the heading, so I would propose to swap the content of the rows making the identifier type the actual link and showing the id in the grey, bottom area which has more space too
Created: 2012-11-21 11:32:33.567
Updated: 2012-11-21 11:32:33.567
Author: kbraak@gbif.org
Comment: [~mdoering@gbif.org] I like your suggestion, switching it around looks great! Please take a look at the attached screenshot. I committed the latest change in http://code.google.com/p/gbif-portal/source/detail?r=1181
Created: 2012-11-22 12:35:25.598
Updated: 2012-11-22 12:35:25.598
Author: kbraak@gbif.org
Comment: Display of alternative identifiers finalized. Closing issue.
Created: 2012-12-03 18:51:53.184
Updated: 2012-12-03 18:51:53.184
