URL's in EML
Tim Bergsma
tbergsma at kbs.msu.edu
Fri Aug 23 08:28:22 PDT 2002
All,
Sorry for not posting this as a reply to Peter's message.
I sense the limitation with regard to URL's as presently specified in
EML, but have been struggling to put it in simple terms for myself.
Here is a brief attempt:
It makes sense to include in EML a pointer to the physical object being
described (even if, as in my case, that 'physical' object will almost
always be a 'virtual' object, created from a database at request time).
However, we are already reaching the point where many sites have many
objects that no person OR machine will ever want to actually look at, as
such: either because they are too large, or for some other reason. In
my case, most of my datasets are perennial; by default I only show the
user the current year, with tools for retrieving other years if
desired. There have been cases where grad students have complained to
me that their browser hangs when they try to download the whole table.
No surprise.
So the urge arises to use EML to tell people and machines that there are
alternatives to downloading the physical object. Looks like this is
what Peter is proposing. I believe that the concept of 'alternative' is
represented by the fact that "the distribution element repeats".
Let me propose a real example, as a test. Shoot me down now if this is
not consistent with the EML vision. My temp/precip data, current on a
weekly basis, is always available at
<http://lter.kbs.msu.edu/Data/table.jsp?Product=KBS002-001>, which I
would list as the URL for the physical object that eml-table documents
(with some modification). However, most users would want to use
<http://lter.kbs.msu.edu/Data/table.jsp?Product=KBS002-001&limitBy=Year&order=desc>
which returns only the most recent year's data by default, including
tools for getting the rest.
Peter: would I treat "table.jsp" as a custom connection, and document
somewhere how the parameters work? Even though it uses a common scheme
(http) it has its own set of usage rules, etc. If not, I have no
problem conceding that there are just some things that I won't be able
to do with EML, or at least with 2.0.
Tim.
--
Tim Bergsma
LTER Information Manager
W.K. Kellogg Biological Station
Michigan State University
Hickory Corners, MI 49060
616/671-2337
tbergsma at kbs.msu.edu
http://lter.kbs.msu.edu
More information about the Eml-dev
mailing list