Deprecate use of accessURL in favor of downloadURL for file downloads

[philipashlock]

To better align with DCAT, I'd suggest that accessURL be deprecated in favor of downloadURL when the URL points to a file for download.

accessURL could still be acceptable but is less specific and would make more sense for URLs that don't lead directly to a download of the whole file such as an API endpoint (rather than webService, see #291) or other information about the resource that's not already captured by dataDictionary, landingPage, or a reference

In related issues: downloadURL should also be paired with mediaType (#272) within the distribution array (#217)

[smrgeoinfo]

is download the only form of access you're countenancing for data.gov?

[gbinal]

👍

@smrazgs - I don't think so, no. It seems to me that this issue is about more tightly aligning to DCAT, making a more exact field for the downloadable file, and to better allow for the use cases described in #333.

[smrgeoinfo]

There seem to be a lot of issues around the basic question of distribution information. in #333 I outlined what are probably the three major scenarios-- a URL that GETs the described resource, a URL that GETs a web application that provides some kind of access to the resource (Is this 'mediated' per @andreamedinasmith in #333 ?), and a link that is machine-actionable to automate access to the resource useful for software agents. I haven't been involved in the F2F discussions that I assume are going on, and its not clear if you have unambiguous solutions for these approaches. The ISO19115 CI_OnlineResource element attempts to address the issue, and it might be worth your time to have a look at that and how its used in metadata instances.

[ktryka]

Just to offer a few different examples of what we have at NIST (which is what @andreamedinasmith was alluding to in #333) :

A database that is available to be searched, and results of search downloaded:

• The landing page would be http://www.nist.gov/pml/data/ffast/index.cfm
• From the landing page you can access a search page : http://physics.nist.gov/PhysRefData/FFast/html/form.html

A database that is available to the public, but for a price:

• The landing page is http://www.nist.gov/srd/nist10.cfm
• From the landing page there are four different forms, depending on whether this is an initial purchase or an upgrade, and depending on whether you are ordering online or need to print a form to fax or mail

The understanding I came away with from the face-to-face last week is that we will put our 'main' page in the landingPage element, and that's pretty much it. Search pages (and certainly not the ordering pages) are not considered to be appropriate for accessURL (which is clearer if you think about accessURL already being downloadURL).

If we want to mention these other pages (search, ordering, etc) those urls will either need to be placed in places that take text (like description, for the search forms, or accessLevelComment, for the ordering forms).

[smrgeoinfo]

It would appear that the data.gov metadata design is not really intended to support describing the variety of distributions that NIST offers. You might consider a more expressive metadata model and catalog service to support the full range of NIST data distribution. Sounds like in the example you give there is no simple click and download link, the simplest distribution is through the search/download web application ('a URL that GETs a web application that provides some kind of access to the resource').

[gbinal]

This is addressed in 1c93d7f

[pandyapm]

Is there any consideration how to represent the QR code (Quick Response code) in the downloadURL?

[philipashlock]

@pandyapm are you asking how you would generate a QR Code based on the downloadURL? I think you would just use the standard alphanumeric encoding scheme for QR codes since that seems sufficient for displaying URLs. That's all defined by the way QR codes work though, so I'm not sure what consideration you think would be appropriate to include here for using QR codes.

[pandyapm]

@philipashlock If there is a QR code image available for an URL, can it be a new field (for e.g. downloadURLQR) inside the distribution list of options?

[philipashlock]

@pandyapm Couldn't the QR code be generated on the fly? This doesn't provide any additional information, it's just an automated transformation of existing information, so I don't think it would be appropriate to include as part of the schema.

[philipashlock]

@smrazgs Just to address your earlier breakdown of the different scenarios:

a URL that GETs the described resource,

For this we're using downloadURL as discussed here

a URL that GETs a web application that provides some kind of access to the resource, and

For this we're using accessURL to describe intermediary resources that can provide access to the downloadURL as discussed in #333

a link that is machine-actionable to automate access to the resource useful for software agents.

For this we're using describedBy as discussed in #332

[gbinal]

Hi folks - It looks like the original issue has been addressed in the v1.1 metadata update.

@pandyapm - I concur with @philipashlock that the QR issue would appear to be a different question. I'm going to go ahead and close this issue but feel free to spin up a new issue for this or anything else.