[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: THREDDS and lightly restricted datasets]

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: [Fwd: THREDDS and lightly restricted datasets]
  • Date: Tue, 30 Mar 2004 12:03:11 -0500
Hi James-
The standard WMO40 policy statement is not that large (in terms of words it's a short para.). The point is that the user must accept the policy and we then store that acceptance in a file for future reference. Of course it's not just a display issue but a use (private sector mostly) and a re-distribution policy. Most state that qualified data providers cannot re-distribute a dataset for 48hrs after creation. These data sets are small in number but a bigger (more important one in my mind) are 'restrictions' by scientists- not wanting their data "out there" yet. A scheme to allow access by colleges via DODS would be most useful. Glenn 
James Gallagher wrote:


Peter, Stefano, Glenn, Benno,

I've been thinking about this and I thought I'd mention an idea Peter
ran by me (I hope that's OK, Peter).

Peter's suggestion: One possibility would be that the client notify the
server that it is aware of the fact that a display policy is required
for a given data set. Without this the server responds with an error.

One slight twist on this would be to have clients include this
'announcement' in every request and to encode the copyright/use info in
every response. This would map easily into the DAP's design and would be
easy to implement using web services stuff, as Stefano points out. 
I suppose the copyright/use policy could be large; do you all know of
any such cases? What I'd like to avoid is a plan that involves
maintaining state at a server or multiple trips to the server. I'd also
like something that will work in both human and machine clients. 
James