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: