Link Type Detection and Display Issues

[fishytodd]

We have more information on how link detection works and where edits need to be made to add new types to our UI (Tanya to add more info below).

Partial list of desired link types that we can already detect:
PDF
CSV
FTP
IMG
KML
TAR
ZIP

[emiliom]

I'm somewhat confused. Many (most?) of these link types have been detected and handled from the start; I just did a quick check on the live portal and can find instances of csv, kml, and zip. So is this supposed to be a list of what's currently detected on the live portal, or what's been added very recently? If the latter, are new additions currently active only on the dev portal or the live portal?

Also, what's the status of "web site" link types? Ditto for OPeNDAP -- though that has its own issue,
#113.

I know @tchaddad is working on this (thanks, Tanya!). Just want to get a clearer ETA so we can plan for Laura's metadata records. Also would like to hear an ETA for when it'll be implemented on the GeoPortal/solr backends, vs the portal UI.

[tchaddad]

Apologies - this probably should not have been in the format of an actual Issue, so I've re-labeled this a question. We just needed something where we could put information for Tim.

Here is a summary of what you need to know about detecting link types in Geoportal:

Geoportal can be configured to detect additional link types largely by editing XML configuration files. There is one XML configuration file for each metatdata type that is harvested. At the moment we are harvesting 4 types of metadata, and we've done a bunch of new work to make the links detected uniform across all of these (before, mostly CSDGM and some 19115 was configured):

• Dublin Core
• CSDGM
• ISO 19115
• ISO 19115-2

Once configured, any new link types can be assigned labels for concise display in the UI. This is done by a 2 step process. First step is an XML configuration, and second step appears to be a Java edit to allow the new label to appear in the JSON that the REST-based UI relies on. See Ecotrust/geoportal-server@f4c6128 for an example from Ryan's work on this topic.

Obviously this latter step is problematic, not because it it difficult, but because it involves recompiling a java class, which is more involved than a standard configuration that can go live automatically.

The net effect of this is that all the link types that we want to detect can be configured to be detected in the XML configurations, but they will not display in the UI until we fix the JSON feed to show the new labels. If we do not fix the labels, the JSON simply refers to all the new link types as "CustomLink".

[emiliom]

That's really helpful, @tchaddad ! Thanks so much for describing the situation so clearly. It's great to have this here for future reference, too.

[tchaddad]

The upshot of this thread is that "extending the Geoportal JSON to display additional detected custom link type labels" (via Ryan's Java edit method above) has become a priority task under the next phase of "enhancement" work we will do.

[tchaddad]

To benefit from the link detection improvements made already the following files should be pushed:

in ////geoportal/WEB-INF/classes/gpt/metadata :

• property-meanings.xml

In ///geoportal/WEB-INF/classes/gpt/search/profiles :

• CSW_2.0.2_OGCCORE_ESRI_GPT_GetRecords_Response.xslt

In ////geoportal/WEB-INF/classes/gpt/resources :

• gpt.properties

In ////geoportal/WEB-INF/classes/gpt/metadata/iso :

• apiso-indexables.xml
• apiso-2-indexables.xml
• iso-19115-2-definition.xml

In ///geoportal/WEB-INF/classes/gpt/metadata/fgdc :

• fgdc-indexables.xml

[timglaser]

The files mentioned in Tanyas most recent comment have been placed on the production server.

[emiliom]

I'm following up on one specific, important link type we've discussed in the past: a link to any generic URL, independent of file or domain name extensions. For example: http://google.com, http://mysite.com/project, etc. Basically a link to an external web location where a user can go to learn more about the dataset (context, organization, other datasets, whatever). @tchaddad's explanations from last week are crystal clear (thanks again!) about what's required at both the GeoPortal and UI ends to detect and expose a link type not currently supported.

I've pointed out before that such "web site" links are actually being detected by GeoPortal in a somewhat generic but potentially accessible way. Basically, it becomes the "Open" link type, as seen in the GeoPortal UI for a metadata record (next to the Details, Metadata, and other link types). I described this in more detail in an email to the WCODP Dev list back in April (but unfortunately the sample metadata records I picked are no longer available, so most/all my links are broken).

As Tanya described:

The net effect of this is that all the link types that we want to detect can be configured to be detected in the XML configurations, but they will not display in the UI until we fix the JSON feed to show the new labels. If we do not fix the labels, the JSON simply refers to all the new link types as "CustomLink".

I read that as also saying that if a link type is available and labelled on the JSON, the UI can use it directly, right now, w/o any changes to GeoPortal whatsoever. It's only UI development work. @tchaddad and @timglaser, is that correct? If so, the "Open" link type is already directly available to us for adding to the UI as a link type.

Here's an example metadata record from Laura Lilly's work, currently on the dev portal; it's called "West Coast Ocean Surface Currents from High-Frequency Radar". The links list in the JSON has an "open" link type with a URL in its 'href' key. That's exactly the URL we want to expose to users on the catalog; it's the first of several entries we included as gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptionsgmd:MD_DigitalTransferOptions elements in the ISO metadata, labelled with a
gmd:protocol/gco:CharacterString of WWW:LINK-1.0-http--related.

Doesn't this all imply that adding the "open" link type to the UI only involves changes to the UI code? And therefore far easier than brand new link types like OPeNDAP that involve changes to GeoPortal as well. I hope so :)

[tchaddad]

Hi Emilio - yes, I think I can confirm to you that if you are happy with a generic label in the UI, then "Open" can be used right now in the UI. We just need to trace the location in the code where the JSON is being interpreted to build that right hand set of links, and add "Open" to the list of displayable types (there are a lot of records that have links of this type, as you've observed).

[emiliom]

Thanks, @tchaddad . Great. I don't have a strong preference about whether the UI labels this link type as "Open" or something else. "Open" seems fine, and we can supplement that with a good tooltip.

It looks like this change would be made here: https://github.com/Ecotrust/wc-data-registry/blob/master/site_raw/_includes/js/directives/Result.js And it might be as simple as adding to scope.allowedLinkTypes a new key-value record like this:

 open: {
label: 'Open',
toolip: "Go to web page with more information"
},

But I'm just guessing here! @timglaser, can you confirm?

[tchaddad]

hehe - best way to know is to try...

(I can test on the dev sever later today)

[emiliom]

Great! I never got around to figuring out (or writing down) all the steps needed to go from changing the UI on github to implementing them on the test server's backend. Go for it! I'll keep fingers crossed ...