Relationship between `activity-status` and `activity-date`s

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

Agree

matmaxgeds:

this points out that my suggestions of actual dates being important should actually refer to planned dates.

That’s what I assumed, glad you confirmed.

matmaxgeds:

As above, if the ruleset enforced forward spending data, then this would change - you wouldn’t need project dates, but could impute them from the spending i.e. date of first transaction = start date, date of last projected transation = end date

Absolutely not! The first transaction is not necessarily the start date, and more importantly the last projected transaction is very/most often not the end date. All kinds of things happen during the course of a project implementation that can require frontloading or delaying transactions.

YohannaLoucheur:

Absolutely not! The first transaction is not necessarily the start date, and more importantly the last projected transaction is very/most often not the end date. All kinds of things happen during the course of a project implementation that can require frontloading or delaying transactions.

Completely understood, but then we have to be clear that the dates associated with activities certainly don’t have a financial meaning - but what meaning do they have? The standard says that “Start dates may reflect either the commencement of funding, planning or physical activity. End dates should, wherever possible, reflect the ending of physical activity.” It could be very different for different donors and different projects - which starts to make it a bit useless if in some cases it means that a team is on the ground, and in other cases it might mean it has been allocated funds internally to the donor but you might not see activity for months? I guess I feel that the ruleset should enforce that the dates need to say which if these things (planning, funding, activity) they refer to in order to be more useful.

matmaxgeds:

Not the answer you are looking for, but if we are going to have rulesets, then I am even less clear that that we need an ‘activity-status’ field given that it can be imputed from the start/end dates and the current date.

matmaxgeds Hmm… Perhaps… But also: removing activity-status would happen at a major upgrade, so that’s a v3.0.0 discussion! Can we park that one?

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

Great – thanks Michelle Levesque !

matmaxgeds:

RE Imputing things - the technical answer to your example is for the date to also reference the timezone that it applies to (is this a feature that we have in the standard?).

It’s not a feature of the standard, no.

Michelle raises a good point here, though. Perhaps some grace period would be good, to allow for these sorts of edge cases?

andylolz:

According to the standard, actual dates must be in the past . But the above rules aren’t currently included in the standard ruleset, or anywhere in the reference documentation. Should they be?

Yes, every MUST in the standard that cannot be validated by the schema MUST have a rule in gthe standard ruleset.

matmaxgeds:

I am even less clear that that we need an ‘activity-status’ field given that it can be imputed from the start/end dates and the current date.

That works for “Implementation” but not for all status codes? (And we’re not in the business of re-egineering the standard at the moment, right?)

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

I agree

matmaxgeds:

I often think that exact dates for activities are fairly meaningless

Given that some exact dates may have meaning the original thinking was that using xsd:date (yyyy-mm-dd)** for all dates - and using the first and last days of the month for non-specific dates - was a pragmatic solution.

** the attibute label @iso-date is misleading as yyyy-mm is valid for ISO 8601 but not for xsd:date. (I think I’m correct on this.) But we’re hardly going to re-engineer the standard now, right?

andylolz:

Perhaps some grace period would be good,

I don’t think we need a grace period for how the validator approaches its work. (It has to be loyal to the standard alone.) The DataStore is a different matter: it should in my opinion ingest future actual dates (or correct them to planned?). No doubt this will arise in the forthcoming consultation on such issues.

Michelle Levesque thanks - this points out that my suggestions of actual dates being important should actually refer to planned dates. Does this mean that you think the ruleset should now reject all activities with actual dates set in the future - @andy can you tell if there are there a lot of these?

RE Imputing things - the technical answer to your example is for the date to also reference the timezone that it applies to (is this a feature that we have in the standard?).

I often think that exact dates for activities are fairly meaningless (and aside from those for calculating loan disbursements would argue for just MM/YYYY) - if the actual start date was the 15th of May, but that is a Saturday and so work started until the 17th of May in reality no-one bats an eyelid - so why does IATI need to be so precise? Most projects have an 30th/31st of the month end date - again, likely to bear little relation to the actual end of activities, in which case we shouldn’t really worry about making dates seem more precise than they are in reality. Otherwise we should start putting in separate dates for the date a transaction was sent, and the date it arrived etc. It is also not clear what part of an activity the dates refer to - i.e. if the donor started thinking about a project in Jan, but its first expenditure was in June, the start date is already pretty useless to many users.

matmaxgeds:

Not the answer you are looking for, but if we are going to have rulesets, then I am even less clear that that we need an ‘activity-status’ field given that it can be imputed from the start/end dates and the current date.

matmaxgeds Hmm… Perhaps… But also: removing activity-status would happen at a major upgrade, so that’s a v3.0.0 discussion! Can we park that one?

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

Great – thanks Michelle Levesque !

matmaxgeds:

RE Imputing things - the technical answer to your example is for the date to also reference the timezone that it applies to (is this a feature that we have in the standard?).

It’s not a feature of the standard, no.

Michelle raises a good point here, though. Perhaps some grace period would be good, to allow for these sorts of edge cases?

andylolz:

According to the standard, actual dates must be in the past . But the above rules aren’t currently included in the standard ruleset, or anywhere in the reference documentation. Should they be?

Yes, every MUST in the standard that cannot be validated by the schema MUST have a rule in gthe standard ruleset.

matmaxgeds:

I am even less clear that that we need an ‘activity-status’ field given that it can be imputed from the start/end dates and the current date.

That works for “Implementation” but not for all status codes? (And we’re not in the business of re-egineering the standard at the moment, right?)

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

I agree

matmaxgeds:

I often think that exact dates for activities are fairly meaningless

Given that some exact dates may have meaning the original thinking was that using xsd:date (yyyy-mm-dd)** for all dates - and using the first and last days of the month for non-specific dates - was a pragmatic solution.

** the attibute label @iso-date is misleading as yyyy-mm is valid for ISO 8601 but not for xsd:date. (I think I’m correct on this.) But we’re hardly going to re-engineer the standard now, right?

andylolz:

Perhaps some grace period would be good,

I don’t think we need a grace period for how the validator approaches its work. (It has to be loyal to the standard alone.) The DataStore is a different matter: it should in my opinion ingest future actual dates (or correct them to planned?). No doubt this will arise in the forthcoming consultation on such issues.

bill_anderson:

Yes, every MUST in the standard that cannot be validated by the schema MUST have a rule in gthe standard ruleset.

The rules mentioned above are not MUSTs in the standard (unless I am mistaken?) I don’t think they’re included anywhere in the reference documentation. Should they be?

 

rules.png785×462 13.7 KB

Bill Anderson Yes – exactly. None of those rules are about the relationship between activity-date and activity-status.

Ah, sorry. Missed that point. Yes, we should have related rules. NB. Amy Silcock Petya Kangalova

andylolz:

According to the standard, actual dates must be in the past . But the above rules aren’t currently included in the standard ruleset, or anywhere in the reference documentation. Should they be?

Yes, every MUST in the standard that cannot be validated by the schema MUST have a rule in gthe standard ruleset.

matmaxgeds:

I am even less clear that that we need an ‘activity-status’ field given that it can be imputed from the start/end dates and the current date.

That works for “Implementation” but not for all status codes? (And we’re not in the business of re-egineering the standard at the moment, right?)

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

I agree

matmaxgeds:

I often think that exact dates for activities are fairly meaningless

Given that some exact dates may have meaning the original thinking was that using xsd:date (yyyy-mm-dd)** for all dates - and using the first and last days of the month for non-specific dates - was a pragmatic solution.

** the attibute label @iso-date is misleading as yyyy-mm is valid for ISO 8601 but not for xsd:date. (I think I’m correct on this.) But we’re hardly going to re-engineer the standard now, right?

andylolz:

Perhaps some grace period would be good,

I don’t think we need a grace period for how the validator approaches its work. (It has to be loyal to the standard alone.) The DataStore is a different matter: it should in my opinion ingest future actual dates (or correct them to planned?). No doubt this will arise in the forthcoming consultation on such issues.

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

Agree

matmaxgeds:

this points out that my suggestions of actual dates being important should actually refer to planned dates.

That’s what I assumed, glad you confirmed.

matmaxgeds:

As above, if the ruleset enforced forward spending data, then this would change - you wouldn’t need project dates, but could impute them from the spending i.e. date of first transaction = start date, date of last projected transation = end date

Absolutely not! The first transaction is not necessarily the start date, and more importantly the last projected transaction is very/most often not the end date. All kinds of things happen during the course of a project implementation that can require frontloading or delaying transactions.

matmaxgeds:

Not the answer you are looking for, but if we are going to have rulesets, then I am even less clear that that we need an ‘activity-status’ field given that it can be imputed from the start/end dates and the current date.

matmaxgeds Hmm… Perhaps… But also: removing activity-status would happen at a major upgrade, so that’s a v3.0.0 discussion! Can we park that one?

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

Great – thanks Michelle Levesque !

matmaxgeds:

RE Imputing things - the technical answer to your example is for the date to also reference the timezone that it applies to (is this a feature that we have in the standard?).

It’s not a feature of the standard, no.

Michelle raises a good point here, though. Perhaps some grace period would be good, to allow for these sorts of edge cases?

andylolz:

According to the standard, actual dates must be in the past . But the above rules aren’t currently included in the standard ruleset, or anywhere in the reference documentation. Should they be?

Yes, every MUST in the standard that cannot be validated by the schema MUST have a rule in gthe standard ruleset.

matmaxgeds:

I am even less clear that that we need an ‘activity-status’ field given that it can be imputed from the start/end dates and the current date.

That works for “Implementation” but not for all status codes? (And we’re not in the business of re-egineering the standard at the moment, right?)

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

I agree

matmaxgeds:

I often think that exact dates for activities are fairly meaningless

Given that some exact dates may have meaning the original thinking was that using xsd:date (yyyy-mm-dd)** for all dates - and using the first and last days of the month for non-specific dates - was a pragmatic solution.

** the attibute label @iso-date is misleading as yyyy-mm is valid for ISO 8601 but not for xsd:date. (I think I’m correct on this.) But we’re hardly going to re-engineer the standard now, right?

andylolz:

Perhaps some grace period would be good,

I don’t think we need a grace period for how the validator approaches its work. (It has to be loyal to the standard alone.) The DataStore is a different matter: it should in my opinion ingest future actual dates (or correct them to planned?). No doubt this will arise in the forthcoming consultation on such issues.

Michelle_IOM:

In my humble opinion I don’t think it makes sense for something that hasn’t finished to have an actual end date nor a project that hasn’t started to have an actual start date. Planned yes. Actual no.

Agree

matmaxgeds:

this points out that my suggestions of actual dates being important should actually refer to planned dates.

That’s what I assumed, glad you confirmed.

matmaxgeds:

As above, if the ruleset enforced forward spending data, then this would change - you wouldn’t need project dates, but could impute them from the spending i.e. date of first transaction = start date, date of last projected transation = end date

Absolutely not! The first transaction is not necessarily the start date, and more importantly the last projected transaction is very/most often not the end date. All kinds of things happen during the course of a project implementation that can require frontloading or delaying transactions.