WCGA / West-Coast-Ocean-Data-Portal

bugs and fixes for the geoportal back end and UI front end of the WCODP
1 stars 0 forks source link

Metadata resource link "Indexables" logic improvement #31

Closed fishytodd closed 9 years ago

fishytodd commented 9 years ago

From Allison - In doing so, I discovered that there are two possible locations for online linkages to go. They are both within the MD_Distribution Section. You can either put them in the gmd:transferOptions section (which is at the same level as gmd:distributor section). Or, you can put them in the MD_Distributor Section in the gmd:distributorTransferOptions which is a subsection of gmd:distributor.

In the WCODP, it looks like it pulls links from gmd:transferOptions, but not from gmd:distributorTransferOptions

I’m wondering if it’s something that could be added to the list for Point97. (Or if it is an easy fix that doesn’t require them). I don’t think there is any reason not to pull from either location. (In fact, I’m not exactly sure why there is a distinction within the metadata standard….).

I’m attaching a couple pages from the ISO metadata workbook showing the hierarchy. Also, I created a metadata record that has the same links in both places so you can see an example. You can also see the outcome on the dev portal if you’re interested: http://wcga-vm01.sdsc.edu/discover/#?s=Sound%20GIS%20Test&text=surfrider

fishytodd commented 9 years ago

From Tanya - I think this sounds like a good ticket for GitHub. There have been a few places where using “or” in the path logic would be nice. The fix can be applied in potentially 2 locations I’m fairly certain that the same type of fix is necessary for these older issues:

cybersea commented 9 years ago

This issue may also be more closely related to https://github.com/Ecotrust/wc-data-registry/issues/117. The detection of online linkages/URLS is not handled in the same location in the JavaScript code as all of the other WCODP metadata content is.

This issue was also noted for metadata created by ncISO: https://github.com/geopython/pycsw/issues/238

tchaddad commented 9 years ago

Alison is correct - this is not a javascript UI fix, it is more a fix on the Geoportal XSLT. I'm fairly certain Christine White has examples of the correct syntax if we can't figure it out on our own. I believe we can attempt the edit before sending to P97.

cybersea commented 9 years ago

I have found another ISO 19115-2 metadata creation tool that is putting data distribution links in gmd:distributorTransferOptions. The ATRAC web-based tool for creating stand-alone metadata or metadata for data archived at NOAA Data Centers. (https://www.ncdc.noaa.gov/atrac/index.html ) This is one of two metadata creation tools that I would like to recommend for our data partners to use because they are very straightforward and easy to use. (The other one being the EPA EME v.4 tool, https://edg.epa.gov/EME/download.html).

Is it possible to move this issue along so that data partners can use these tools without having to manually edit the XML file afterwards to put the URLs in the other location?

I and/or Tim are happy to provide help with this if needed.

cybersea commented 9 years ago

I just noticed that one of the URLs in gmd:distributorTransferOptions, a KML, has shown up in the WCODP interface. Mysterious...

See: http://wcga-vm01.sdsc.edu/discover/#?s=Sound%20GIS%20Test&text=Mooring

fishytodd commented 9 years ago

Example of REST links not appearing from Romsos (http://wcga-vm01.sdsc.edu/geoportal/rest/document?id={34984053-4171-4AB8-AC06-94416249BF56}). srv:connectPoint gmd:CI_OnlineResource gmd:linkage gmd:URL http://hornet.coas.oregonstate.edu/arcgis/rest/services/2014_BOEM/Primary_Lithologic_Habitat_WA_OR_NCA/MapServer

fishytodd commented 9 years ago

example of record not showing WMS links (http://wcga-vm01.sdsc.edu/geoportal/rest/document?id={8CFD0970-8640-4C0C-9DB7-F6EFD1909FFD})

srv:connectPoint gmd:CI_OnlineResource gmd:linkage gmd:URL http://pdx.axiomalaska.com/ncWMS/wms?service=WMS&version=1.3.0&request=GetCapabilities /gmd:URL

fishytodd commented 9 years ago

example of zip showing up as "open" http://wcga-vm01.sdsc.edu/geoportal/rest/document?id={892bd1f1-d26f-4a2c-b132-1e9e445a913c}

gmd:citedResponsibleParty gmd:CI_ResponsibleParty

gmd:contactInfo gmd:CI_Contact gmd:onlineResource gmd:CI_OnlineResource gmd:linkage gmd:URL http://coastalscience.noaa.gov/datasets/ccma/biogeo/cinms/Chap_4_Data/RECFIN_fish_div_5min.ZIP

tchaddad commented 9 years ago

This last example (things showing up as "open") is unrelated to the XSLT.

It is a bug we somewhat intentionally introduced back in late-Oct Nov.

tchaddad commented 9 years ago

I think this issue (and the various items mentioned in it) was handled by the fixes pushed to Dev this afternoon.

If @fishytodd and @cybersea agree, then we can close this one

cybersea commented 9 years ago

Thanks Tanya -- great work! This makes ISO 19115-2 play much better with the Portal.

My only concern is that we lost the HTML links (OPEN) from ISO 19115 and ISO 19115-2 when the URL is located in transferOptions. This breaks the Surfrider metadata that was working previously.

/gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:distributor/gmd:MD_Distributor/gmd:distributorTransferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource/gmd:linkage

The HTML links work when links are in distributorTransferOptions /gmi:MI_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:distributor/gmd:MD_Distributor/gmd:distributorTransferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource/gmd:linkage

You can compare behavior in ISO 19115, transferOptions (Not showing html): http://wcga-vm01.sdsc.edu/geoportal/rest/document?id={98AAE242-DB9E-4B73-B3F5-6C850218B1B0}

ISO 19115-2, transferOptions (not showing html): http://wcga-vm01.sdsc.edu/geoportal/rest/document?id={9E163105-A41A-411F-9953-10D44342AF21}

ISO 19115-2 distributorTransferOptions (works): http://wcga-vm01.sdsc.edu/geoportal/rest/document?id={2031C17E-DEF9-4DA5-9003-0206C9259C9C}

tchaddad commented 9 years ago

Ah ok - thanks for pointing this out. I was looking for an example where the OPEN tweak would have adverse affects, and now I have one to follow up on....

tchaddad commented 9 years ago

Looking at these a second time I believe these ones will be easily solvable:

ISO 19115, transferOptions (Not showing html): http://wcga-vm01.sdsc.edu/geoportal/rest/document?id={98AAE242-DB9E-4B73-B3F5-6C850218B1B0}

ISO 19115-2, transferOptions (not showing html): http://wcga-vm01.sdsc.edu/geoportal/rest/document?id={9E163105-A41A-411F-9953-10D44342AF21}

However, the Surfrider records are a different problem, and going to be a bit more difficult. Stay tuned...

cybersea commented 9 years ago

Perusing the full catalog on the dev portal (with changes) as compared to production (without changes), I'm seeing the following things:

On the dev portal, the use of the OPEN link has completely vanished, except for the Sound GIS Test records, and ones from CENCOOS (Aquarius for example) and OSU (Source = NANOOS). In all these cases, it is displaying .html URLs in the OPEN link. These records are not using the HTML link. So, probably all the ISO 19115-2 metadata.

The HTML link is used in many other examples -- see records from WA dept of Ecology, DNR, (Source Washington Geospatial Clearinghouse).

With the loss of the OPEN link, we are now not seeing these types of URLs: .aspx (example Digital Offshore Cadastre) /texthere/ (example ROE National Land Cover data or National Wetlands Inventory /texthere (example California Ocean Uses Atlas, http://portal.westcoastoceans.org/discover/#?text=uses%20a)

tchaddad commented 9 years ago

Hmm, I think I expected some of this, but there are several things tangled in here (multiple label types) so I think I need to take a closer look.

My aim here is to get away from using the HTML label, and instead have the OPEN link go to things that are HTML, ASP, root urls, etc. Basically anything that is not a service link. If something is a data or service link, then it gets a custom label, everything else gets an OPEN link.

Thanks for pointing at the examples so I can compare. Super helpful...

emiliom commented 9 years ago

+1 to Tanya's aim :

My aim here is to get away from using the HTML label, and instead have the OPEN link go to things that are HTML, ASP, root urls, etc. Basically anything that is not a service link. If something is a data or service link, then it gets a custom label, everything else gets an OPEN link.

tchaddad commented 9 years ago

Looking at this issue, I believe the original topic of "indexable logic" has been fixed (we are now looking for URLs in the correct locations for all metadata types, and all service URL types).

The remaining portion of the problem relates to problems with the "OPEN" label. I suggest we close this original ticket, and move the portion about the "OPEN" problem to a new issue.

cybersea commented 9 years ago

Sounds good to me @tchaddad