Add resourceTimePeriod

[jlblcc]

                      "resourceTimePeriod": {
                          "description":"Period of resource",
                          "beginPosition":"1977-12-14",
                          "endPosition":"2007-08-13"
                        }

[stansmith907]

I suggest we

• add the resourceTimePeriod under citation
• use the format for an ISO TimePeriod
• and change beginPosition and endPosition to startDate and endDate
• although all dateTime formats would be permitted.
• implementation in ISO will show the start and end dates in a separate EX_Extent with a single temporalElement.

        "resourceInfo": {
            "citation": { },
            "resourceTimePeriod": {
                "description": "",
                "startDate": "0000-00-00",
                "endDate": "0000-00-00"
            }
        }

[dwalt]

While I like the proposal, would this entail creating a second extent if
there is a geospatial component, or would we add that to the same extent?
This issue being clearinghouse acceptance of multiple extents.

On Wed, Oct 29, 2014 at 10:41 AM, stansmith907 notifications@github.com
wrote:

I suggest we

• add the resourceTimePeriod under citation

• use the format for an ISO TimePeriod

• and change beginPosition and endPosition to startDate and endDate

• although all dateTime formats would be permitted.

• implementation in ISO will show the start and end dates in a
  separate EX_Extent with a single temporalElement.

  "resourceInfo": {
      "citation": { },
      "resourceTimePeriod": {
          "description": "",
          "startDate": "0000-00-00",
          "endDate": "0000-00-00"
      }
  }
  

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[jlblcc]

When you say:

add the resourceTimePeriod under citation

You're not suggesting to add this to the citation object?

I would prefer to use the same schema for time period, i.e. leave beginPosition and endPosition. That makes more sense schema-wise.

[stansmith907]

under extent

I was just referring to the position of the object in the adiwgJson, it would not be part of the citation object.

would this entail creating a second extent?

I think we should place the temporalElement in its own extent - not attached to any geographic object, which could have its own temporal extent describing the geometry.

I would prefer to use the same schema for time period

It doesn't cause me any problems in the reader to use different names than we use in temporal element. And since this is mostly a descriptor for projects I thought using more "project friendly" names would be nice. Is this an issue for the schema? The object name is already different - "resourceTimePeriod" - but that is likely a different matter.

[jlblcc]

I'd have to write another schema object since the property names are different.

[stansmith907]

Then let's stick with beginPeriod and endPeriod. There not terrible.

[stansmith907]

We need some rules ...

• resourceTimePeriod - optional (recommended for projects)
• description - optional
• beginPeriod, endPeriod - at least one of these are required

[jlblcc]

Added to schema, see: http://www.adiwg.org/mdJson-schema-viewer

[stansmith907]

I know that earlier I said resourceTimePeriod should not be an array. I'm having second thoughts. Should we allow multiple time periods to allow expression of non-contiguous activity?

[jlblcc]

I say folks can use an extent for that. I think we should define the resourceTimePeriod as the period covering the entire span, regardless of breaks, for which there was/is/expected to be resource activity, i.e. start/end date. Otherwise, why not just drop resourceTimePeriod and use extent?

[stansmith907]

Works for me. Just double checking while I'm in the program.

[dwalt]

Ran across this from data.gov, project open data. Scroll down to spatial
and temporal sections.

http://project-open-data.github.io/schema/

On Wed, Oct 29, 2014 at 3:23 PM, stansmith907 notifications@github.com
wrote:

Works for me. Just double checking while I'm in the program.

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[stansmith907]

Pushed mdTranslator 0.8.7 w/ support for resource time period.

Josh - before you publish the translator gem you might want to edit the gemspec to set a matching ADIwg-json-schema version. Also, I noticed the json-schema gem version jumped from 2.2 to 2.4.1 yesterday. Any chance it covers our windows problem?

[stansmith907]

That's a horrible JSON structure! (I felt like I needed to tweet that)

[jlblcc]

My pull request, voxpupuli/json-schema/pull/109, is still sitting there, but there's been some comments on it in the last few days. Maybe it'll be resolved soon.

I need to build another adiwg-json-schemas gem...