Metadata resource link "Indexables" logic improvement

[fishytodd]

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]

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:

•      https://github.com/Ecotrust/wc-data-registry/issues/100 and possibly
  

•      https://github.com/Ecotrust/wc-data-registry/issues/99
  

  which are about Dublin Core Metadata.
  Not sure if this is only an edit on the UI side, or if anything is necessary on the Geoportal side.

[cybersea]

This issue may also be more closely related to Ecotrust/wc-data-registry#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: geopython/pycsw#238

[tchaddad]

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]

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]

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]

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]

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]

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:organisationName gco:nilReason="missing"/>
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]

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]

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]

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]

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]

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]

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]

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]

+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]

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]

Sounds good to me @tchaddad