Timestamp, Duration and Stored

[rswetnam]

Apologies in advance if this has already been discussed and I missed it. (

The spec includes two properties for a statement - timestamp and stored. Timestamp presumably represents the point in time whereas Store represent when the statement data was entered in the LRS. I have a couple of concerns, suggestions:

1. There doesn't seem to be any requirement for a time duration in the spec. I think that most learning experiences take place over time and as a consumer of LRS information, it would make a difference to me knowing whether my surgeon has spent 1 week or 7 years learning his craft. I believe that it might be useful to require that a start time be required as I believe is the case with SCORM or some sort of duration field. Right now, I can't tell whether timestamp represents when the learning experience was completed or started. Duration would represent the time over which the learning experience occurred - full time or part time.
2. I think the term timestamp could be confusing - at least for those who inhabit the .Net world. I think in the spec, it's meant to signify a point in time. For Ms-SQL server timestamp
   is a data type that exposes automatically generated binary numbers, which are guaranteed to be unique within a database.
3. What is the rationale for including stored in the requirement? Is it because in analyzing info retrieved from an LRS, we might deem that if there is too great a difference between stored and timestamp, the info is less reliable? If so, it seems to be a circuitous way of determining this.
4. I would replace the current property names with WhenStarted, WhenFinished and if there is a justification that I am not aware of -WhenStored.

[garemoko]

Hi @rswetnam,

1. Take a look at the result.druation property. This is optional as not all experiences have a measured duration.
   2 and 4. We're not going to change property names. The end user should never see these names and changing them will be a breaking change. Any benefit of a better name, even if the current name is truly awful, is not worth breaking existing implementations.
2. Stored is one of the most important properties of the statement. In systems involving multiple LRSs, or an LRS and some other system that stores statements, the stored property is used by the fetching system to get statements it does not already have. So if I last fetched statements at 3pm Thursday, I can fetch all statements with a stored property since 3pm Thursday to get up to date (In fact I have to go a little earlier than 3pm, but you get the idea). Differences between timestamp and stored do no reflect reliability in any way.

On started vs. finished, see the second paragraph here and #337

[rswetnam]

Thanks @garemoko for this - makes sense.

[canweriotnow]

@rswetnam I would suggest that the stored property could even be used (in theory) to resolve your UUID issue - if two statements are identical except for ID, some resolution based on first-stored could be added as a proviso in a future version. Still think the UUID issue is bikeshedding (or at best a corner case), but maybe there's a solution there.

Hey, @andyjohnson, since @rswetnam seems to accept @garemoko's response, can we close this?