[GILS Logo]

gils: Re: FW: GILS Profile Version 2 Changes

gils: Re: FW: GILS Profile Version 2 Changes

Re: FW: GILS Profile Version 2 Changes

Eliot Christian (echristi@usgs.gov)
Sat, 28 Sep 1996 04:58:59 -0400 

Message-Id: <2.2.32.19960928085859.006e7e90@isdmnl.wr.usgs.gov>
Date: Sat, 28 Sep 1996 04:58:59 -0400
To: gils@cni.org
From: Eliot Christian <echristi@usgs.gov>
Subject: Re: FW: GILS Profile Version 2 Changes

At 01:13 PM 9/24/96 -0700, you wrote:
>[...] Can you change the wording to indicate that at least one or 
>both forms can be used. (same for Available Time Period).

OK, done.

>2. I  note that you have reversed the sequence of Time Period Structured 
>and Time Period Textual.  Structured now comes first.  Was there a reason 
>for the reversal? 

As we discussed on the telephone, it's a bit easier if the textual stuff
comes first since it is not repeating and may be intended to explain the
strctured dates. 

BTW, I don't think one should expect all servers, clients, and record
creation software to adhere strictly to the order in which the profile lists
elements.

>3. You could add to the definition for Time Period that if Time Period 
>Structured is used, then at least the Beginning Date must be supplied. 
>(same for Available Time Period).

It seems to me that having a beginning date only could mean the time period
is just one year or there is no ending date because the resource is still
active. Perhaps the single year could be covered by having the same value
for the beginning date and ending date. 

Can anyone comment on the conventional behavior of date period searching
when the ending date is absent or when you have the same beginning date and
ending date?

>4. I have not looked closely at ISO 8601 or the MARC format for dates 
>prior to AD.1.  In the Can. Guidelines I specify the use of ISO 8601 
>for AD dates and the format used with in the NARA Guidelines for other 
>types of dates, e.g. B.C. Era to 9999 B.C.  which are based on the 
>Content Standards for Digital Geospatial Metadata.  All this date stuff 
>is really outside my expertise.

Me, too. Anyone else have any thoughts?

>5. If Time (hours, min., secs.) is really required by a certain community 
>of GILS users , e.g. Geographic, geospatial, can't this element be made 
>a local one?

Sure it could be. I am inclined to not specify time beyond the date
component if we don't have to--it looks to become pretty complicated.

Eliot Christian, US Geological Survey, 802 National Center, Reston VA 20192
echristi@usgs.gov  Office 703-648-7245  FAX 703-648-7069  Home 703-476-6134

[CNI Home Page]