Need Stable Links to Open-Data Item-Details Pages

[IvanBrown]

We have a main open-data group that we use to serve most (hundreds) of our open-data items to our open-data portal. To help the user get to certain popular data more efficiently, we:

1. Moved items of certain popular categories from our site's main open-data group to separate topic-oriented open-data groups--to keep them out of search-bar search results.
2. Made topic-oriented Hub pages; hardwired open-data links by making URLs using this pattern: <host>/datasets/<Item ID as obtained from URL of item-details page> . For example: "https://geodata.vermont.gov/datasets/e12195734d38410185b3e4f1f17d7de1_17".  (Note: We noticed that the ending number is the item's ID + _ + REST Layer-ID)

This worked for a while. Then, the links stopped working (404 errors); we got the links working again by switching /datasets/ to /items/ in the URL pattern.

That worked for a while. Then it stopped working (back to 404 errors). We then added the popular-category items to the site's main open-data group (co-locating them in the topic-category group and the main group). This partially solved the problem; although the topic-oriented Hub-page links work (by the way, /items/ is dynamically switched to /datasets/), because the popular-category items are also in the main open-data group, they show up in search-bar results.

We don't want popular-category items to show up in search-bar results (a giant pile of items); we want the topic-oriented Hub page to be the gateway from the search bar (or from elsewhere) to streamlined topic-focused browsing (search bar --> Hub Page --> hardwired item-links).

The bottom line question--how do we get a stable URL for an open-data item to hardwire it to a Hub page w/o including it in our site's main open-data group?

[Anonymous User]

Hi Ivan,

Thanks for reaching out.

First off, apologies for the changes to your urls. When we launched the new version of search, we had some issues between the /items routes and the /datasets routes, which have since been resolved. /items should no longer appear anywhere on your site and the /datasets/{{ id }} urls should work now and long into the future. That said, I know it can be frustrating when changes break elements of your site and requires significant effort to fix on your end. We are doing our best to make sure that doesn't happen again.

Secondly, there is no way to manually remove items from your search index without unsharing them from the site. When we were designing the new search, we took note of the strategies many of our customers have used to improve the ways their end users get to the content they're looking for. To that end, we made several enhancements to search, including the autosuggestions that come in the search bar and the addition of site pages to search. One of the top comments we received from our users was that they wished their pages had greater visibility on sites. We agreed and thought one of the best ways to get end users to the great pages you create was to add them to the search index alongside your datasets, documents, and apps. We understand this might cause some redundancy with the content discovery strategies employed on many sites, but we hope that the changes we made will improve the content experience across the platform without having to use such workarounds. Our site analytics suggest that search success has increased since release and we hope that translates to increased satisfaction for your end users. 

Again, apologies that the changes we made caused problems for your site but we hope overall the trend for your users is up and to the left.

Best,

Patrick, Hub Product Engineer

[VCGIvanBrown]

Thanks for your help w/ this back in 2019. Now, in the 2021 environment, I'm returning to the goal of providing stable links to open-data items.

The URL that appears in the address bar when finding and selecting an ArcGIS Online feature-layer-based item has a pattern that goes like this <host>/datasets/<a string that obviously comes from the item's title>/explore?location=.......  . I could share/link that URL as-is; however, is it guaranteed to be stable? What happens if the item's title string is altered?

When I access an item via the title-based URL, the Info Updated date and the Published Date have dates that are the same as in the item's metadata--which is what I want.

In Hub documentation, I found this page on supported content--a page that has clues on URL routes to content. According to that page, it looks like the URL pattern for a stable URL would be <host>/datasets/<id>/explore.

However, when I follow the <host>/datasets/<id>/explore pattern, the Info Updated date and the Published Date don't show dates from the item's metadata; they show dates that look like system dates (Published Date appears to be when the item was born in the ArcGIS Online system, not the published date in the item's metadata from when the dataset was born on a different platform).

When I try a similar id-based pattern that appends an _<layer ID> to the id (for example, <host>/datasets/<id>_0/explore for layer number 0 in the feature service), the Info Updated date and the Published Date do show dates that are in the item's metadata--which, again, is what I want.

To make note, I have observed that the Data Updated date drifts a little between these approaches, but not by more than a few days (maybe a lag?). We use the FGDC CSDGM metadata style. There's no direct FGDC CSDGM equivalent to Data Updated, and Data Updated automatically changes when the layer's data is reloaded/changed--which is what I want; I want Data Updated to be system-generated and the other two dates (Info Updated and Published Date) to show as they are in the item's metadata.

With my preference for metadata dates, what is the best way to provide/link stable URLs in the current environment?