Improvements to Duration Profile

[jeannekitchens]

Improvements are needed to support use cases where duration data needs to be explictely identified as based on calendar time or clock time. Working with a research group that needs to use Registry data to calculate cost based on time. e.g., cost per month to earn a credential brought the use cases and issues forward that need to be addressed.

Below is a typical example where both time scales, calendar and clock are useful:

The Learning Program / Course / Learning Opporunity / Credential takes 2 months to complete and 20 hours of time over that 2 month period.

Currently there are no properties for explicitely differentiating calendar and clock time. This proposal is to resolve this issue.

Add the following properties:

ceterms:exactTimeRequired
Definition: Hours or minutes to complete the activty or event measured by a clock.
Comment: This includes hours and minutes.
Usage Note: Use exactDuration for time measured on a calendar including years, months, weeks and days.
Domain: ceterms:DurationProfile
Range: schema:Duration

ceterms:minimumTimeRequired
Definition: Minimum hours or minutes to complete the activty or eventmeasured by a clock.
Comment: This includes hours and minutes.
Usage Note: Use minimumDuration for time measured on a calendar including years, months, weeks and days.
Domain: ceterms:DurationProfile
Range: schema:Duration

ceterms:maximumTimeRequired
Definition: Maximum hours or minutes to complete the activty or event measured by a clock.
Comment: This includes hours and minutes.
Usage Note: Use maximumDuration for time measured on a calendar including years, months, weeks and days.
Domain: ceterms:DurationProfile
Range: schema:Duration

Update the following properties:

ceterms:exactDuration
Definition: Change from, Exact period of time of an activity or event. To Exact period of time of an activity or event based on calendar time.
Comment: This includes years, months, weeks, and days.
Usage Note: Use exactTimeRequired for time measured by a clock including hours and seconds.
Domain: ceterms:DurationProfile
Range: schema:Duration

ceterms:minimumDuration
Definition: Change from Minimum amount of time it will take to complete the activity. To Minimum amount of time it will take to complete the activity based on calendar time.
Comment: Change from, The value of ceterms:minimumDuration denotes an approximation of duration. To, Change from, The value of ceterms:minimumDuration denotes an approximation of duration including years, months, weeks, and days.
Usage Note: Use minimumTimeRequired for time measured by a clock including hours and seconds.
Domain: ceterms:DurationProfile
Range: schema:Duration

ceterms:maximumDuration
Definition: Change from, Maximum amount of time it will take to complete the activity. To Maximum amount of time it will take to complete the activity based on calendar time.
Comment: Change from, The value of ceterms:maximumDuration denotes an approximation of duration. To, The value of ceterms:maximumDuration denotes an approximation of duration including years, months, weeks, and days.
Usage Note: Change from, Do not use ceterms:maximumDuration to identify the renewal frequency of a credential; use ceterms:renewalFrequency instead. To, Do not use ceterms:maximumDuration to identify the renewal frequency of a credential; use ceterms:renewalFrequency instead. Use maximumTime for time measured by a clock including hours and minutes.
Domain: ceterms:DurationProfile
Range: schema:Duration

Preferred Approach

https://drive.google.com/file/d/1fXzXzEXCiccs0fchXxJNGLXvsvX7Arre/view?usp=sharing

Other Approaches

[siuc-nate]

We should probably look at updating the comments (and maybe definitions) for the various properties unique to Duration Profile to further clarify which ones to use in which scenarios.

I would not, however, restrict the timeRequired properties to only hours and minutes. That might make sense as a recommendation and a way to express what they're meant for, but unless we know that 100% of all cases will never need more than that, we can't do that (it would probably require a range other than schema:Duration if we did, anyway, since that spec allows for all of the other time fields).

[siuc-nate]

Here are my suggested revisions to clarify and harmonize definitions/comments/usage notes. I borrowed from Jeanne's calendar/clock notion for the comments, and tried to just come out and say what we really mean in the usage notes to maximize clarity.

ceterms:estimatedDuration

• Old Definition: Estimated time it will take to complete a credential, learning opportunity or assessment.
• New Definition: Estimated time it will take to complete an activity, event, or resource.

ceterms:exactDuration

• Old Definition: Exact period of time of an activity or event.
• New Definition: Exact overall span of time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 50 hours over a span of 6 months to complete, use this to record 6 months.
• New Comment: This is intended to indicate time as typically measured by a calendar, regardless of what portion of that time is spent actively pursuing the completion of the activity, event, or resource.

ceterms:minimumDuration

• Old Definition: Minimum amount of time it will take to complete the activity.
• New Definition: Minimum overall span of time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 50 hours over a span of 3-9 months to complete, use this to record 3 months.
• Old Comment: The value of ceterms:minimumDuration denotes an approximation of duration.
• New Comment: This is intended to indicate time as typically measured by a calendar, regardless of what portion of that time is spent actively pursuing the completion of the activity, event, or resource.

ceterms:maximumDuration

• Old Definition: Maximum amount of time it will take to complete the activity.
• New Definition: Maximum overall span of time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 50 hours over a span of 3-9 months to complete, use this to record 9 months.
• Old Comment: The value of ceterms:maximumDuration denotes an approximation of duration.
• New Comment: This is intended to indicate time as typically measured by a calendar, regardless of what portion of that time is spent actively pursuing the completion of the activity, event, or resource.

ceterms:exactTimeRequired

• New Definition: Exact total engaged or participating time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 50 hours over a span of 6 months to complete, use this to record 50 hours.
• New Comment: This is intended to indicate time (as typically measured by a clock) which is spent actively pursuing the completion of the activity, event, or resource.

ceterms:minimumTimeRequired

• New Definition: Minimum total engaged or participating time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 15-20 hours over a span of 6 months to complete, use this to record 15 hours.
• New Comment: This is intended to indicate time (as typically measured by a clock) which is spent actively pursuing the completion of the activity, event, or resource.

ceterms:maximumTimeRequired

• New Definition: Maximum total engaged or participating time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 15-20 hours over a span of 6 months to complete, use this to record 20 hours.
• New Comment: This is intended to indicate time (as typically measured by a clock) which is spent actively pursuing the completion of the activity, event, or resource.

[jeannekitchens]

@siuc-nate I like your defintions but why use "typically measured by a clock". It would be a problem to have calendar time end up there. Why not just say this is for time measured by a clock. Use the other for time measured by a calendar?

You're fast!!!

[siuc-nate]

I used "typically" because in most cases, yes, you would use hours/minutes to measure that time, even if such hours exceeded 24. However:

• If at any point/in any use case there is ever a data publisher that wants to express that detail in something bigger than hours, we can't restrict that unless we're willing to say "no" to such a publisher (in other words, consider it an edge case that we have decided not to cover).
• Since we claim the range of the property is schema:Duration and since schema:Duration allows for the full set of time-related attributes, we can't limit it. It would be like saying "the range is a number, but really only numbers 0-3 are valid".
• I see any limitation in this regard as an implementation detail rather than a schema one (in other words, the Registry profile might not allow publishers to express anything in units bigger than hours, but the schema shouldn't have that limitation).
• Data in the wild might want to describe something (perhaps unrelated to courses etc) using ceterms:DurationProfile where the time required needs to be in units bigger than hours.

I would also apply the above logic to avoid limiting (at least at the schema level) the duration properties to just those units greater than hours.

[mparsons-ce]

Re: express anything in units bigger than hours
In this case exactDuration would be used.
Otherwise there would be no difference between exact duration and exact time.

[mparsons-ce]

Just a note that there are existing durations that use two parts like years and months, and hours and minutes.

[siuc-nate]

If we end up automating republishing of data after making this change, it would probably be safe to assume we should use the timeRequired properties for things that use clock units. We might want to manually look into any that have a particularly high number of hours (or any that use factions of days, for that matter)

[philbarker]

I typed a reply yesterday but maybe didn't hit the right button.

Anyway, @siuc-nate's new definition for esitmatedDuration has "time" rather than "overall span of time" like the others, which seems like an oversight?

I don't think we should get into whether time is measured with a clock or whatever: some learning opportunities and assessments have durations of hours. (e.g. short CPD courses may be only a single afternoon session). You may want instead to say that durations may be measured in any convenient unit from seconds to years or mixes of them, e.g. P1.5Y, P1Y6M, P18M.

I think timeRequired will always be an estimate, it's just in the nature of people and their interaction with tasks that some people take longer than others. Even when the time allocated is fixed, e.g. for an assessment, some people will finish early, some people won't finish in the time available.

So, on reflection, I think it is not only needlessly complex but also a mistake to use the full duration profile to provide min/max/estimated/exact durations for timeRequired. I think we should refine the definitions for duration as Nate's outlines above, to make sure the intent of providing the total time elapsed between start and end; and add a new property:

name: timeRequired
[there may be better names, such as estimatedTime]
definition: Approximate or typical time needed to do the work associated with a resource, recorded using ISO 8601.
Comment: If a course lasts 8 weeks, and students are expected to do 10 hours work per week on it, the timeRequired will be estimated at PT80H.
usage note: Time required is usually provided in hours. Use duration to record the total time that elapses between the start and end of an learning opportunity, assessment or other type of event.

[siuc-nate]

I intentionally left my suggestion for estimatedDuration a little broader since that is the property that points to the Duration Profile itself. Unfortunately we kind of have two (or three?) subtly different uses of the word "duration" involved in this, so I wanted to be super clear at the definition level which thing meant what.

So, on reflection, I think it is not only needlessly complex but also a mistake to use the full duration profile to provide min/max/estimated/exact durations for timeRequired

If it is the case that time required is constant regardless of anything else, then we can get away with putting such a property at the root level (ie on the Course directly). But if it ever needs to be contextualized and/or if there are ever two or more such values for that property that need some kind of description or need to be grouped with relevant durations, then the property needs to go in Duration Profile.

I am a little more open to not having minimum/maximum time required properties, but I am weary of consuming the "timeRequired" URI now in the event that we do have to come back later and add such properties. Then there would be a disjoint in the intended parallels:

• exactDuration
• minimumDuration
• maximumDuration
• timeRequired
• minimumTimeRequired
• maximumTimeRequired

I could live with it, I guess, but I think it is worth considering.

Comment: If a course lasts 8 weeks, and students are expected to do 10 hours work per week on it, the timeRequired will be estimated at PT80H.

I did the others as usage notes; are you saying these should be comments instead? Also, I don't want to require any kind of interpretation or calculation (like the reader needing to realize that the 8 weeks was multiplied by 10 to arrive at 80) that might lead to confusion, hence "x hours over a span of y months" in my phrasing.

[philbarker]

If it is the case that time required is constant regardless of anything else, then we can get away with putting such a property at the root level (ie on the Course directly). But if it ever needs to be contextualized and/or if there are ever two or more such values for that property that need some kind of description or need to be grouped with relevant durations, then the property needs to go in Duration Profile.

I am a little more open to not having minimum/maximum time required properties, but I am weary of consuming the "timeRequired" URI now ...

OK, how about estimatedTimeRequired, which (a) emphasises that it will by its nature be an estimate and (b) gives us the opportunity to use others if they ever turn out to be needed.

The other points—comments vs usage notes and the wording—I'm not too worried about, go with what is consistent with other terms.

[siuc-nate]

What is our comfort level with rejecting edge cases (e.g. two or more different values for timeRequired that may or may not be scoped to two or more different durations)?

In other words, if a partner comes along someday and wants to publish data like that, are we okay with saying "no, the schema does not and will not support that" to that partner?

[philbarker]

In other words, if a partner comes along someday and wants to publish data like that, are we okay with saying "no, the schema does not and will not support that" to that partner?

Or we say: partner, you have what we consider to be two different things.

Edit: for example, two pathways to the same credential based on what knowledge the learner starts with, two scheduled offerings.

[siuc-nate]

I agree, but, there is a fair bit of additional overhead (more entities, publishing workflows, linking, CTID management, etc) associated with that (vs just having two Duration Profiles on a Course/Credential with different values for timeRequired), and we've seen that not all partners are keen on that level of depth.

I'm trying to avoid a situation where we do this the simple way now, change our minds later, and thereby incur a bunch of technical debt because now all of our implementations have to change to move the timeRequired data into Duration Profile and off of the root object (and republish existing data, and do something to avoid breaking partners' publishing systems). Doing it the more complex way now means those last few edge cases are preemptively handled when they eventually do arise and we don't have to worry about it.

The alternative is to say that, for the sake of doing this the simple way, those few edge cases are off the table forever - and while I'm open to that, it is not something we are usually keen on saying.

[philbarker]

I know where you are coming from, but you're also not often keen on building in complexity just to cope with potential use cases for which we have no evidence. We lose something either way.

If the key point is not burning the requiredTime property name in case we need it for something more in parallel with duration later. Is there any name you can think of that avoids that? TBH, I would rather keep in parallel with LRMI/Schema.org/IEEE P2881 and use timeRequired the way they do and think of something different if we ever need it. The original question seems like a one we answered 10 years ago.

We could at a push allow timeRquired on a duration profile if there is ever the case that the estimated amount of work required depends only on how long you take before starting and finishing and there is no other object to group them, but again, we could hold that back for if we ever need it (I don't like it, it seems like a misuse of the duration property to treat its value like that, and don't think we should encourage it).

[siuc-nate]

I would need a little more insight into what it is you're proposing first. Are you suggesting requiredTime be a single-value property directly on Course et al with a range of schema:Duration (that is to say, a duration-formatted string)? Or are you proposing something else?

[philbarker]

Still this:
name: timeRequired
[there may be better names, such as estimatedTime]
definition: Approximate or typical time needed to do the work associated with a resource, recorded using ISO 8601.
Comment: If a course lasts 8 weeks, and students are expected to do 10 hours work per week on it, the timeRequired will be estimated at PT80H.
usage note: Time required is usually provided in hours. Use duration to record the total time that elapses between the start and end of an learning opportunity, assessment or other type of event.

But I see now that today I forgot to unclude

domain: [same as duration]
range: xsd:duration

[siuc-nate]

The name is worth discussing, yeah. I don't have a terribly strong feeling on it, I just want to be careful with it.

Shouldn't we keep the definition and comment in line with the suggested changes for the duration properties? In particular, I would prefer the clarity of explicitly stating the number of hours in both parts of the example (unless there is a reason to require the calculation?).

I assume you mean the same domain as ceterms:estimatedDuration?

I would also suggest using schema:Duration instead of xsd:duration for consistency with ceterms:exactDuration/ceterms:minimumDuration/ceterms:maximumDuration. The reason we went with schema:Duration for those was that it allows for "weeks" whereas xsd:duration does not.

[philbarker]

I'm not too worried about the details of the definition and comment, I'm fine with consistency the rest of CTDL.

I assume you mean the same domain as ceterms:estimatedDuration?

yes, sorry I was getting myself confused (and slightly confused by it being possible to provide an exactDuration for an estimatedDuration).

In that case the parallel term name would be estimatedTimeRequired.

I'm ok with using schema:Duration for the range so long as it is clear that values will be literals of the ISO8601 format like "PT40H" (FWIW, I think time required is unlikely to be in weeks, I borderline on saying it should always be in hours, our examples should always be in hours). That seems to be what we do currently.

[Aside, the example I checked has a "ceterms:exactDuration": "P128WT1920H" which looks like an example of the type of mess we are trying to avoid. I guess it is 4x32week Academic years, 15 hours per week (see also this); so the data neither duration nor time required, just some numbers they had.]

[siuc-nate]

Do we need three properties in Duration Profile:

• exactTime(Required)
• minimumTime(Required)
• maximumTime(Required)

Or just timeRequired? It came up in a meeting today that we may or may not want to keep the word "required" as part of the property, and we may or may not need all three properties.

[jeannekitchens]

We need to have the three time properities that are based on the timespan properties to parallel the duration properties and alllow people to have time spans. It makes sense that something could be between e.g., 5 to 7 hours. For example, assessments often have time spans and then pencils/keyboards down.

[jeannekitchens]

Futher if e.g. a course is open entry and open exit / self paced, there can be a duration in clock time rather than calendar time. Also, in the U.S. carnegie credits issues for postsecondary courses is base on clock time not calendar time. There are major efforts with competency-based education to not use clock time at all, rather the basis is demonstrating competencies.

[philbarker]

We need to have the three time properities that are based on the timespan properties to parallel the duration properties and alllow people to have time spans. It makes sense that something could be between e.g., 5 to 7 hours.

So timeRequired which is by definition approximate, would be 6 hours

For example, assessments often have time spans and then pencils/keyboards down.

That's duration, right? The assessment lasts 3 hours (clock time, but still duration). Hopefully the estimated time required to do the assessment will be a little less.

Futher if e.g. a course is open entry and open exit / self paced, there can be a duration in clock time rather than calendar time.

So timeRequired is (e.g.) 30 hours and duration is undefined.

Can you think of any example where the time required to work through the material of a course can be exactly defined in anyway that isn't set by the duration of the event (as with the Assessment example)?

[philbarker]

After today's meeting, I think I can live with @siuc-nate's take on putting timeRequired on DurationProfile because if we think of approximateDuration->DurationProfile as indicating something kind of similar to a Scheduled Offering in giving duration-related aspects of a resource. I predict the naming will confuse a lot of people, but mostly I don't want to discuss this much more as I think we have solved the key issue that was leading to poor data like that I mentioned in this post

[siuc-nate]

As we discussed, here are some example JSON blobs:

First, a vanilla example of a course with one duration and one timeRequired, and no frills:

{
  "@type": "ceterms:Course",
  "ceterms:estimatedDuration": [
    {
      "@type": "ceterms:DurationProfile",
      "ceterms:exactDuration": "P6W",
      "ceterms:timeRequired": "PT30H"
    }
  ]
}

Next, a Learning Opportunity (of some sort) that requires 120 hours of engaged work regardless of whether you do that in-person with everyone else, or on your own time/schedule:

{
  "@type": "ceterms:LearningOpportunityProfile",
  "ceterms:estimatedDuration": [
    {
      "@type": "ceterms:DurationProfile",
      "ceterms:description": { "en": "In-class students will participate in a six month schedule." }
      "ceterms:exactDuration": "P6M",
      "ceterms:timeRequired": "PT120H"
    },
    {
      "@type": "ceterms:DurationProfile",
      "ceterms:description": { "en": "Self-paced students will have up to one year to complete the work, but may be able to finish it in a few months." }
      "ceterms:minimumDuration": "P3M",
      "ceterms:maximumDuration": "P1Y",
      "ceterms:timeRequired": "PT120H"
    }
  ]
}

Next, some other kind of Learning Opportunity where certain aspects can be skipped by passing some kind of quiz or exam to show that you already know that part of the material (leading to two different estimations for time required):

{
  "@type": "ceterms:LearningOpportunityProfile",
  "ceterms:estimatedDuration": [
    {
      "@type": "ceterms:DurationProfile",
      "ceterms:description": { "en": "Beginners typically complete the material in 30 days." }
      "ceterms:minimumDuration": "P20D",
      "ceterms:maximumDuration": "P40D",
      "ceterms:timeRequired": "PT30H"
    },
    {
      "@type": "ceterms:DurationProfile",
      "ceterms:description": { "en": "Experienced individuals may test out of certain lessons, and complete the material in as few as 10 days." }
      "ceterms:minimumDuration": "P10D",
      "ceterms:maximumDuration": "P25D",
      "ceterms:timeRequired": "PT20H"
    }
  ]
}

[mparsons-ce]

It appears there is now consensus that time/effort/etc required will be on the duration profile, so I will focus my comments based on that context.
I believe that timeRequired should never be allowed without the related duration, as a key driver to adding this property is to indicate the effort within a duration.
If a value like the following was encountered, a person would not know the timespan (days, weeks, months) where the time is being spent. Is it: 3 days at 10H/day, Or 3 weeks at 10H/week, etc.

{
  "@type": "ceterms:Course",
  "ceterms:estimatedDuration": [
    {
      "@type": "ceterms:DurationProfile",
      "ceterms:timeRequired": "P30H"
    }
  ]
}

Also, if duration is in hours, I would think that timeRequired would not be used/allowed.
In this example, if the exact duration is 10 hours, what else could time required be but 10 hours?

{
  "@type": "ceterms:Course",
  "ceterms:estimatedDuration": [
    {
      "@type": "ceterms:DurationProfile",
      "ceterms:exactDuration": "PT10H",
      "ceterms:timeRequired": "PT10H"
    }
  ]
}

I don't believe an assessment that could take 5 - 7 hours, would have anything but a exact duration of 7 hours.
Sure if you study real hard, you make complete it earlier, but the latter is not related to the scheduled length of the assessment.

So related to this, I think that timeRequired would always be in hours or minutes - especially where, as noted above, timeRequired can only be provided with duration, not instead of duration.

[siuc-nate]

If a value like the following was encountered, a person would not know the timespan (days, weeks, months) where the time is being spent. Is it: 3 days at 10H/day, Or 3 weeks at 10H/week, etc.

I think it would be safe to assert a ceterms:minimumDuration of 30 hours, in that case. It could take longer, but it wouldn't take less time. Is that something the API can automatically fill in?

Also, if duration is in hours, I would think that timeRequired would not be used/allowed.

I don't see any practical benefit to this restriction. Something with a timeRequired of 10 hours is naturally going to have a minimum duration of 10 hours as well (per your previous point). The unit of measurement shouldn't make any difference.

Put another way: I don't understand why we would allow someone to say "the duration is 1 day and the timeRequired is 24 hours" but we wouldn't allow someone to say "the duration and the time required are both 24 hours". They are technically two different measurements of two different things that just happen to fall on the same place on the proverbial measuring tape - I don't think we gain anything by preventing both assertions from being made.

I don't believe an assessment that could take 5 - 7 hours, would have anything but a exact duration of 7 hours.
Sure if you study real hard, you make complete it earlier, but the latter is not related to the scheduled length of the assessment.

This came up in a discussion at some point - I think it was @philbarker who said the min/max duration would be 5/7 hours and the estimated time would fall somewhere in the middle (depending on what the publisher wants to assert).

So related to this, I think that timeRequired would always be in hours or minutes - especially where, as noted above, timeRequired can only be provided with duration, not instead of duration.

It most likely would, but I don't see the benefit in restricting it. What do we gain by saying "no one may ever assert a timeRequired measured in anything larger than hours"? Why is a timeRequired of 72 hours any more or less valid than a timeRequired of 3 days?

We also need to keep in mind that the source data in publishers' systems (and/or the limitations of their technical capabilities/willingness to change the data/etc) may not allow for forcing a translation to hours/minutes for timeRequired from some other unit of measurement.

[siuc-nate]

Policy issues aside, it seems like we're in agreement that timeRequired should be a property of Duration Profile. However, there were some questions hanging about the definition/comment/usage note of that property (and the other related properties). I would think we would want these definitions/comments/usage notes to harmonize. Here's a slight adjustment to what I suggested several posts ago as a starting point (I removed a little of the "exact"ness from them and revised the comments):

ceterms:estimatedDuration

• Old Definition: Estimated time it will take to complete a credential, learning opportunity or assessment.
• New Definition: Estimated time it will take to complete an activity, event, or resource.

ceterms:exactDuration

• Old Definition: Exact period of time of an activity or event.
• New Definition: Overall span of time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 50 hours over a span of 6 months to complete, use this to record 6 months as P6M.
• New Comment: This is intended to indicate overall time span, regardless of what portion of that time is spent actively pursuing the completion of the activity, event, or resource.

ceterms:minimumDuration

• Old Definition: Minimum amount of time it will take to complete the activity.
• New Definition: Minimum overall span of time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 50 hours over a span of 3-9 months to complete, use this to record 3 months as P3M.
• Old Comment: The value of ceterms:minimumDuration denotes an approximation of duration.
• New Comment: This is intended to indicate overall time span, regardless of what portion of that time is spent actively pursuing the completion of the activity, event, or resource.

ceterms:maximumDuration

• Old Definition: Maximum amount of time it will take to complete the activity.
• New Definition: Maximum overall span of time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 50 hours over a span of 3-9 months to complete, use this to record 9 months as P9M.
• Old Comment: The value of ceterms:maximumDuration denotes an approximation of duration.
• New Comment: This is intended to indicate overall time span, regardless of what portion of that time is spent actively pursuing the completion of the activity, event, or resource.

ceterms:timeRequired

• New Definition: Total engaged or participating time it will take to complete the activity, event, or resource.
• New Usage Note: If a resource takes 50 hours over a span of 6 months to complete, use this to record 50 hours as PT50H.
• New Comment: This is intended to indicate only the sum of the individual amounts of time which are spent actively engaged in pursuing the completion of the activity, event, or resource, regardless of the overall time span required to complete it.

Given the discussions that have happened since then, do we need to make further changes to the above?

[philbarker]

On the policy issues, I agree with Nate. You can have an open-book exam/test with duration of 24 hours for which the time required is 8 hours.
Time required is usually measured in hours even when that corresponds to several days, and I think our examples should reflect this (as Nate's do), but I don't think there is much to be gained by insisting on this.

I like Nate's definitions, but I think some encoded values would be useful, especially if we can show the difference between P30M and PT30M.

[siuc-nate]

Good point - I edited encodings into each usage note's example.