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 https://github.com/Ecotrust/geoportal-server/commit/f4c61285e96eb38d548c2a7ce6c18eabd80e6f71 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 ...

[emiliom]

@tchaddad, I assume you didn't find the time to make this change (ie, "web site / Open" link type) on the dev server? Then, I suspect you'll be swamped this week and next week with FOSS4G (which I'm not attending, wha-wha!).

I can volunteer to make the change myself and submit a pull request. But then someone with admin privileges on the github repo would have to accept the pull request, and someone would have to deploy it on the server, run jekyll, etc. I never learned how to do that. Oh, and it'd also be best if we had confirmation from @timglaser that we're on the right track, before investing a good chunk of time. Tim?

So, Tanya, does it sound like this is not something we can make meaningful progress on (ie, not just the github change, but deployment on the dev server) for the next two weeks?

[tchaddad]

Actually - I was on the road last week and I made the change, but ran into an upload roadblock and had to pass the file to @fishytodd because the folder permissions were not set for our group. Todd has it now, and can push it soon. Apologies for the lack of follow-up here - technically I'm still on the road...

[emiliom]

Wow, @tchaddad ! Thanks! BTW I don't see the changes on Results.js on this github repo, so I assume you made the edit directly on the file on the dev server and bypassed github? Just curious. @fishytodd , thanks for handling this; let me know when the change is in place, so we can see if it worked.

[fishytodd]

Hey all, uploaded the new file (Thanks TH) and restarted Geoportal. Not exactly sure how to check and see if it was successful, but please verify and let me know if I can do anything else.

TH

On Wed, Sep 3, 2014 at 4:43 PM, Emilio Mayorga notifications@github.com wrote:

Wow, @tchaddad https://github.com/tchaddad ! Thanks! BTW I don't see the changes on Results.js https://github.com/Ecotrust/wc-data-registry/blob/master/site_raw/_includes/js/directives/Result.js on this github repo, so I assume you made the edit directly on the file on the dev server and bypassed github? Just curious. @fishytodd https://github.com/fishytodd , thanks for handling this; let me know when the change is in place, so we can see if it worked.

— Reply to this email directly or view it on GitHub https://github.com/Ecotrust/wc-data-registry/issues/117#issuecomment-54385109 .

Todd R. Hallenbeck | Program Coordinator

West Coast Ocean Data Portal West Coast Governors Alliance Cell: (408) 482-6807 todd.r.hallenbeck@westcoastoceans.org http://portal.westcoastoceans.org

[emiliom]

Thank you, @fishytodd !! I've checked the dev portal. I looked at Laura's records. The link types labelled "Open" are the new ones, and as you can see, 4 of the 5 records have them. WOO-HOO!! This is really awesome. FYI, @tchaddad, the only thing that was missed was the link-type hover-over help text on the "i" icon; and I can see that was MY fault: the code fragment I gave earlier mispelled the dictionary key "tooltip", and used "toolip" instead. So sorry. Tanya probably copied and pasted my code fragment.

[fishytodd]

Nice, thats great news. I noticed that depending on the record the "open" pulls a website or a zip file, in either case they were not being displayed for those records previously.

If the only change needs to be the correct spelling of tooltip then I can probably change the results.js file and upload the new version.

Thanks Tanya!

tH

On Wed, Sep 3, 2014 at 5:13 PM, Emilio Mayorga notifications@github.com wrote:

Thank you, @fishytodd https://github.com/fishytodd !! I've checked the dev portal. I looked at Laura's records http://wcga-vm01.sdsc.edu/discover/#?s=West%20Coast%20IOOS. The link types labelled "Open" are the new ones, and as you can see, 4 of the 5 records have them. WOO-HOO!! This is really awesome. FYI, @tchaddad https://github.com/tchaddad, the only thing that was missed was the link-type hover-over help text on the "i" icon; and I can see that was MY fault: the code fragment I gave earlier mispelled the dictionary key "tooltip", and used "toolip" instead. So sorry. Tanya probably copied and pasted my code fragment.

— Reply to this email directly or view it on GitHub https://github.com/Ecotrust/wc-data-registry/issues/117#issuecomment-54387626 .

Todd R. Hallenbeck | Program Coordinator

West Coast Ocean Data Portal West Coast Governors Alliance Cell: (408) 482-6807 todd.r.hallenbeck@westcoastoceans.org http://portal.westcoastoceans.org

[fishytodd]

OK, I corrected the spelling error and it looks like the appropriate tooltip is now showing up. Teamwork! I will work with Tim G to make sure this gets pushed to production before our next big launch.

TH

On Wed, Sep 3, 2014 at 5:31 PM, Todd Hallenbeck <todd.r.hallenbeck@gmail.com

wrote:

Nice, thats great news. I noticed that depending on the record the "open" pulls a website or a zip file, in either case they were not being displayed for those records previously.

If the only change needs to be the correct spelling of tooltip then I can probably change the results.js file and upload the new version.

Thanks Tanya!

tH

On Wed, Sep 3, 2014 at 5:13 PM, Emilio Mayorga notifications@github.com wrote:

Thank you, @fishytodd https://github.com/fishytodd !! I've checked the dev portal. I looked at Laura's records http://wcga-vm01.sdsc.edu/discover/#?s=West%20Coast%20IOOS. The link types labelled "Open" are the new ones, and as you can see, 4 of the 5 records have them. WOO-HOO!! This is really awesome. FYI, @tchaddad https://github.com/tchaddad, the only thing that was missed was the link-type hover-over help text on the "i" icon; and I can see that was MY fault: the code fragment I gave earlier mispelled the dictionary key "tooltip", and used "toolip" instead. So sorry. Tanya probably copied and pasted my code fragment.

— Reply to this email directly or view it on GitHub https://github.com/Ecotrust/wc-data-registry/issues/117#issuecomment-54387626 .

Todd R. Hallenbeck | Program Coordinator

West Coast Ocean Data Portal West Coast Governors Alliance Cell: (408) 482-6807 todd.r.hallenbeck@westcoastoceans.org http://portal.westcoastoceans.org

Todd R. Hallenbeck | Program Coordinator

West Coast Ocean Data Portal West Coast Governors Alliance Cell: (408) 482-6807 todd.r.hallenbeck@westcoastoceans.org http://portal.westcoastoceans.org