| Issue 4: | Date in TemporalCoverage element | |
| 1 person starred this issue and may be notified of changes. | Back to list |
In the official EML Schema, the TemporalCoverage element use SingleDateTime element as a Type of singleDateTime element and rangeOfDates element; but in the GBIF Schema the data type used for those elements is calendarDate. Official EML Schema: <xs:element name="singleDateTime" type="SingleDateTimeType" maxOccurs="unbounded"> </xs:element> GBIF EML Schema: <xs:element name="singleDateTime" type="calendarDate"> </xs:element>
Sep 27, 2010
Project Member
#1
wixner@gmail.com
Sep 27, 2010
Basically the only difference that I can identify is that in the calendarDate element, the GBIF EML Schema use type NMTOKEN: <xs:element name="calendarDate" type="xs:NMTOKEN"> ... </xs:element> But in the Official EML Schema the calendarDate use other type: <xs:element name="calendarDate" type="res:yearDate"> </xs:element> and yearDate has another attribute (union): <xs:simpleType name="yearDate"> ... <xs:union memberTypes="xs:gYear xs:date"/> </xs:simpleType>
Oct 4, 2010
well, that in deed makes a difference then. We need to reuse the original yearDate simple type in that case. Please just update our calendarDate element and make it use the yearDate simple type which you will have to copy over to our schema first.
Status:
Accepted
Oct 4, 2010
(No comment was entered for this change.)
Labels:
-Priority-Medium Priority-Critical
Oct 4, 2010
fixed in r149. The yearDate simple type already was added in the file.
Status:
Fixed
Cc: wixner
Oct 8, 2010
There is another important defect in this part: In the Temporal Coverages page, the user is allowed to chose one of the following date types: - Single Date - Living Time Period - Formation Period - Date Range However, the temporalCoverage element in the schema, only allows to add two date types: "Single Dates" and "Range of Dates". The other date types are adding in the additionalMetadata element wich is used internally for GBIF. In the General EML Schema, there exists others elements that can be used as an "alternative time scale" - timeScaleName --> for Geological Dates etc... This information should appear as sub-elements of temporalCoverage and not in additionalMetadata.
Status:
Accepted
Oct 8, 2010
this is correct, but Eamon limited the complexity of the Eml and only selected the pieces of it that seem most useful. So we dropped the alternativeTimeScale for example. As its part of a choice in the original schema, ours fixes the singleDate to always a calendar date. The living time period btw is quite similar to the eml alternativeTimeScale...
Status:
Invalid
Oct 8, 2010
In that case, can you make a quick look to the cardinality of the formationPeriod element? Because, in the page, the user is allowed to add several formation periods, but in the GBIF Schema it only permitted to add one: <xs:element name="formationPeriod" type="NonEmptyStringType" minOccurs="0"> In contrast with the LivingTimePeriod element which permits several cases: <xs:element name="livingTimePeriod" type="NonEmptyStringType" minOccurs="0" maxOccurs="unbounded">
Status:
New
Oct 11, 2010
according to the NCD 0.9 document both should be repeatable: Formation Period: Text description of the time period during which the collection was assembled e.g. "Victorian", or "1922 - 1932", or "c. 1750". R L So the gbif profile should be changed and formationPeriod be made unbound. Yup!
Status:
Accepted
Oct 11, 2010
NCD 0.90: http://www.tdwg.org/standards/312/download/
Oct 15, 2010
(Additional Metadata - Date Published): pubDate element also has been changed to be a calendarDate type. r218. |