NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On Jul 2, 2012, at 12:26 PM, Doug Lindholm wrote: > Hi Dennis, > > I am going to spin off a new thread for this one. > > I'm inclined to agree that DAP2 doesn't currently provide the best > abstraction for data access. What concerns do you have about it and how do > you think CDMRemote addresses them? Others out there, do you have cases of > OPeNDAP request syntax short-comings? > > I'll point out that I am a big fan of REST and GET. I'd be curious to hear > more about the GET vs POST issues (maybe in another thread?), but I'm only > concerned about GET, for now. I note an affinity for "name=value" parameters > in REST APIs. Is there anything in REST practices that require this? Do > others consider OPeNDAP (which does not adhere to this convention) to be > RESTful? Well, I consider DAP2 to be a REST API ;-) James > > For example, instead of "data.nc?req=CDL" in the CDMRemote examples, I would > simply say "data.cdl". Although I've seen many OPeNDAP servers point to > actual NetCDF files, I consider "data" in this case simply as a resource - a > virtual dataset. "data.nc" tells me that I should expect a NetCDF file as a > response. Saying that "data.nc" is the "endpoint" seems to expose an > implementation detail - that the data come from a specific NetCDF file. It's > the suffix "cdl" (or "das" or "dods"...) that specifies the output format. > Maybe a little unconventional compared to most REST interfaces, but it's > consistent with OPeNDAP. > > After a quick glance, I also don't see how the CDMRemote request syntax is > significantly different from OPeNDAP. OPeNDAP's hyperslab notation seems to > support the index subsetting, and selection constraints like "longitude>22.8" > could be used in place of "south=22.8". Is there something I'm missing in > those examples? (I'll save the ncstream vs dods protocol discussion for > another time.) > > I've been working on a new data model for our OPeNDAP server (LaTiS). It is > largely inspired by Unidata's CDM, DAP2, and VisAD. One thing that strikes me > is that CDM (and many other data models) seem to leap to a domain specific > "feature type" definition prematurely. At some level, I can say that my > variable is a function of two variables (think two dimensional): > > (X,Y) -> MyVariable > > At a higher level, I can say that X is longitude and Y is latitude so I now > have a GeoGrid. However, there are lots of things you can do with a more > generic view of a 2D variable (think polymorphism). No need to exclude > astronomers or anyone else that has a 2D problem domain. And it gets more > interesting when you start thinking about a 2D variable being a function of > arity 2 from a Functional Programming perspective. If anyone knows anything > about category theory, type classes, contravarience, partial functions, > currying,... in Scala, I'd love to talk with you. > > Doug > >> IMO DAP2 queries are not usable for specifying server-side operations. >> There is too much missing. >> DAP4 is a possibility although I am not sanguine on the prospects >> given the way it is evolving. >> John Caron's CDMremote seems like a better candidate. >> Visad also would be promising for its data model, but >> as far as I know, there is no remote access protocol >> using visad. >> >> =Dennis Heimbigner >> Unidata > > _______________________________________________ > thredds mailing list > thredds@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ -- James Gallagher jgallagher at opendap.org 406.723.8663
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
thredds archives: