Consider the following (imaginary) list of files:
1997360.nc 1998001.nc 1998007.nc 1998013.nc ... 1997361.nc 1998002.nc 1998008.nc 1998014.nc 1997362.nc 1998003.nc 1998009.nc 1998015.nc 1997363.nc 1998004.nc 1998010.nc 1998016.nc 1997364.nc 1998005.nc 1998011.nc 1998017.nc 1997365.nc 1998006.nc 1998012.nc 1998018.nc
These appear to be a set of netCDF files, arranged by date3
If you want data from the first week of January, 1998, it is fairly
clear which files to request. However, the OPeNDAP server provides
no way to request data from more than one file, so your request would
have to be split into 7 different requests, from 1998001.nc to
1998007.nc. This could be represented as a set of seven DODS
URLs:
http://opendap/dap/data/1998001.nc http://opendap/dap/data/1998002.nc http://opendap/dap/data/1998003.nc http://opendap/dap/data/1998004.nc http://opendap/dap/data/1998005.nc http://opendap/dap/data/1998006.nc http://opendap/dap/data/1998007.nc
But what if you then uncover another similar dataset whose data you want to compare to the first? Or what if you want to expand the inquiry to cover the entire year? Keeping track of this many URLs will quickly become burdensome.
What's more, another similar dataset could be arranged in two
different directories, 1997 and 1998, each with files:
001.nc 002.nc 003.nc ...
and so on. Now you have to keep track of two large sets of URLs, in two different forms. But you could also imagine files called:
0011998.nc 0021998.nc 0031998.nc
or
00198.nc 00298.nc 00398.nc
or
1Jan98.nc 2Jan98.nc 3Jan98.nc
That is, the number of possible sensible arrangements may not, in fact, be infinite, but it may seem that way to a scientist who is simply trying to find data.