cron specification for schema

[satra]

would a cron specification like the following work?

at the activity set or activity levels:

    "cronTable": [
        {"random_delay": "2:0:0", "schedule": "0 8 * * *", "isAbout": "phq9"}, #example 1a
        {"random_delay": "2:0:0", "schedule": "daily", "isAbout": "phq9"},   #example 1b

        {"random_delay": "30:0", "schedule": "0 8 * * 1", "limit": "2-0", "isAbout": "mmse"},  #example 2a
        {"random_delay": "30:0", "schedule": "monthly", "limit": "2-0", "isAbout": "mmse"}, #example 2b
       ...
    ],

random_delay and limit are specified as time deltas of the form [[[[[YY-]MM-]DD-]HH:]MM:]SS

@zaliqarosli @akeshavan @sanuann @shnizzedy - let us know if this sounds ok.

tentative glossary:

key	description
random_max_delay	Present activity/item within some random offset of activity available time up to the maximum specified by this
schedule	set make activity available/repeat info using cron format
limit	limit the duration this activity is allowed to be completed by once activity is available
isAbout	pointer to the node describing the item
max_retakes	number of times the item is allowed to be redone

my preference is not to allow options 1b and 2b in the schema

[zaliqarosli]

looks fine to me! i'll let you know if we need something different but i don't think that's the case

[zaliqarosli]

@satra could you please elaborate on what this is for?

[satra]

@zaliqarosli - this would be primarily used in settings where activities are repeated in an activity set (for example, daily monitoring, monthly reminders, etc.,.)

[ccraddock]

How would you specify that a activity should expire after some period of time?

Essentially, make this activity available at a specified time and make it unavailable some delta_time later?

[satra]

@ccraddock - see limit in the table above.

ps. we would ensure the names are all appropriate before incorporating this into the schema.

[ccraddock]

I saw limit, but perhaps I misunderstand your use of the word 'start'. I am dividing the task timing into two phases (although Arno would argue for more, I am limiting to the two for now), one is when the activity becomes available for user to complete, and the other is when the user actually begins performing the activity. I interpret your definition of limit to mean that it limits the duration after the user has begun the activity. What I am asking for is a limit to the amount of time that a user has access to the activity. This would cause the activity to become unavailable if the user doesn't do the activity within the time window.

We need another key word.

[ccraddock]

actually, the amount of time that a user has to complete the activity once it is started would probably be handled by a different aspect of the system. So it could be that the 'limit' term that you defined could be used for the amount of time that a activity is available to complete, and the time window for completing the task once started would be defined within the activity definition.

[satra]

@ccraddock - i think i follow. i have reworded it as activity available. so limit is describing how much time the user has to start the activity after it being available.

for a given activity/activityset, the node itself could define how long the user has to complete once started. for example, like a timed exam. we can introduce a keyword for that property (e.g. timelimit).

[satra]

an example if timing is already included in some of the value constraints. this is for an audio task:

https://github.com/ReproNim/schema-standardization/blob/master/activities/voice_task/items/pataka_valueConstraints.jsonld#L7

but it would likely be useful to have something that can be set at any level of the hierarchy and how it would interact with/constraint other things. i will try to clean up the keywords and propose a final list next week.